streamlabs-mcp

Server Quality Checklist

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

Latest release: v2.0.1
Disambiguation4/5
Most tools have distinct resource-action pairs. The three audio listing tools (streamlabs_list_audio_sources, streamlabs_list_all_audio_sources, streamlabs_list_audio_sources_for_scene) have overlapping purposes but are differentiated by scope. Overall, descriptions are clear enough to disambiguate the majority of tools.
Naming Consistency5/5
All tools follow a consistent streamlabs_verb_noun pattern, making the naming highly predictable. Minor deviations like streamlabs_get_sources_by_name and streamlabs_create_and_add_source are still readable and fit the overall convention.
Tool Count2/5
With 59 tools, this server far exceeds the typical well-scoped range. Many granular tools (flip_x, flip_y, rotate, center, fit, stretch) could be consolidated into one transform tool, and several notification and scene collection operations add bulk. The count feels bloated.
Completeness4/5
The tool surface covers the core streaming workflow: scenes, sources, audio, streaming controls, studio mode, scene collections, and notifications. Minor gaps exist (e.g., no tool for reordering scene items or setting output settings), but these are not critical for most use cases.
Average 3.7/5 across 59 of 59 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 4 commits in the last 12 weeks
- Last stable release on August 13, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
This server has been verified by its author.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral transparency. It discloses that the origin point is optional and affects the scaling, but it does not explain whether the scale is absolute or relative, how the coordinate system works, or any side effects on the scene item's transform. This is a significant gap for a mutating tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler words, making it highly concise and front-loaded. However, it is so brief that it omits necessary context, but that is more a completeness issue than a conciseness problem.
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?
The tool has 5 parameters, nested objects, no annotations, and no output schema, making it moderately complex. The description only covers the core action and one optional aspect (origin), leaving out essential behavioral details like scale coordinate system, interaction with existing transform, and any prerequisites. Sibling tools further highlight the need for clearer differentiation, which is absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It adds meaning to 'origin' by indicating it is a pivot point, but it does not explain the semantics of 'scale' (e.g., multipliers) or the relationship between sceneId, sourceId, and sceneItemId. The nested object fields (x, y) are left entirely to the schema, which only provides type information.
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 ('Set the scale of a scene item') and specifies the resource (a scene item). It also mentions the optional origin point, which adds specificity. However, it does not explicitly distinguish this from the sibling tool set_scene_item_transform, which may also affect scale.
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 implies usage when you want to scale a scene item, but it gives no explicit guidance on when to choose this tool over alternatives like set_scene_item_transform or fit_scene_item_to_screen. There are no exclusion criteria or prerequisite conditions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for disclosing behavioral traits. It merely states the action without mentioning side effects (e.g., whether it overrides existing position, preserves scale, or affects locked items). It also fails to clarify why three identifiers are needed or how they relate. This is minimal for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is immediately clear and front-loaded with the action verb. Every word is purposeful, and there is no redundant 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 mutation tool with three required parameters and no annotations or output schema, this description is inadequate. It does not explain what 'center' means operationally, why all three parameters are necessary, or what the expected outcome is. The tool is too thin for an agent to invoke confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no explanations for sceneId, sceneItemId, or sourceId. The purpose of sourceId is particularly ambiguous—does it identify the source attached to the scene item? The description adds zero value beyond the schema's bare property names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Center') and the resource ('a scene item on the canvas'). It is specific enough to distinguish this tool from sibling tools like set_scene_item_transform or fit_scene_item_to_screen, as centering is a unique operation.
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 tool versus alternatives, such as when to use fit_scene_item_to_screen or set_scene_item_scale. The description gives no context about scenarios that favor centering, nor does it exclude other tools. This leaves the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 of behavioral disclosure. 'Rename a scene' implies a mutation, but it does not mention effects on existing state, duplicate name handling, error conditions, permissions, or whether the operation is reversible. This is minimal transparency beyond the action itself.
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, front-loaded sentence with no filler, repetition, or unnecessary detail. It is appropriately sized for the simple operation it describes.
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?
Despite low complexity, the lack of annotations, output schema, and any parameter descriptions leaves important context unstated, such as how to obtain a valid sceneId, whether newName must be unique, and what the tool returns or does on failure. The description is too sparse to be considered complete for agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention sceneId or newName at all. With zero schema descriptions, the description was expected to compensate for parameter meaning, but it adds nothing beyond the parameter names themselves.
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 the specific verb 'Rename' and identifies the resource 'scene,' clearly distinguishing it from sibling tools that list, get, switch, create, remove, or clear scenes, and from rename_scene_collection. It is unambiguous and immediately communicates the tool's function.
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, no prerequisites (e.g., obtaining a sceneId via streamlabs_list_scenes), and no exclusions. An agent must rely solely on the tool name and schema to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. It only states the literal rename action; it does not indicate effects on the active collection, naming constraints, error conditions, or reversibility. This is insufficient for a mutating operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler, and the information is front-loaded. However, its extreme brevity results in under-specification, though that is captured in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and zero schema coverage, the description is too sparse to fully support correct invocation. It lacks guidance on required IDs, behavior when the collection does not exist, and any side effects. A minimal viable description would at least mention the parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention the parameters at all. The agent must rely on the parameter names (collectionId, newName), which are somewhat self-explanatory, but no additional meaning or constraints are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Rename') and the resource ('scene collection'), distinguishing it from sibling tools like streamlabs_rename_scene and streamlabs_rename_source. It is specific and unambiguous.
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 information about when to use this tool versus alternatives, nor any exclusions or prerequisites. There is no mention of how it relates to list/load/create/delete scene collection siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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, but it only states the core action. It doesn't mention side effects, requirements, permissions, or what exactly changes beyond the flip operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundant words. It is appropriately short for a simple action, though it lacks any structural elements like parameter explanations.
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 with 3 required parameters, no annotations, and no output schema, the description is insufficient for an agent to understand invocation context or parameter relationships. It doesn't explain what the parameters represent or what result to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description provides no parameter information. The roles of sceneId, sceneItemId, and sourceId are not explained, leaving the agent to infer entirely from parameter names.
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 'Flip a scene item horizontally' uses a specific verb + resource + direction, clearly distinguishing it from the sibling flip_scene_item_y tool. It precisely states what the tool does.
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 implies this tool is for horizontal flipping, but it does not explicitly state when to use it versus alternatives like flip_scene_item_y or other transform tools. No exclusions or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only states the action without mentioning side effects, permissions, whether the notification will appear in the panel, or any state changes. The description adds minimal behavioral context beyond 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?
The description is a single, focused sentence with zero filler. Every word contributes to stating the tool's action and target, achieving high conciseness without sacrificing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but the description omits contextual details that would help an agent, such as whether the notification appears in the Streamlabs Desktop notifications panel or how it relates to sibling notification tools. It is minimally viable but not fully complete given the absence of annotations and output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description is completely silent about parameters. It does not explain the meaning of 'message' or 'type', nor how the enum values (INFO/SUCCESS/WARNING) affect the notification. The schema provides the only parameter details, and the description adds no compensatory value.
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 ('push') and resource ('new in-app notification in Streamlabs Desktop'), clearly distinguishing it from sibling tools like streamlabs_list_notifications or streamlabs_mark_notification_read. It is unambiguous and directly states the tool's purpose.
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 the notification management alternatives. It does not mention any conditions, prerequisites, or exclusion criteria, leaving the agent to infer usage from the tool name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. It states the operation but does not mention that it overwrites existing transform values, potential side effects, permission requirements, or error conditions. This is a mutation with untold consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that immediately communicates the core action. It is well-structured and avoids clutter, though it could have used the space to clarify parameters without losing conciseness.
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?
The tool is simple, but with three required parameters, no annotations, and no output schema, the description should clarify how the parameters relate and what 'default' means. It notably omits any explanation of sourceId, which is puzzling alongside sceneItemId. The description is not complete enough for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description does not explain any of the three parameters (sceneId, sceneItemId, sourceId). The parameter names are self-descriptive but the role of sourceId is unclear, and there is no indication of which scene item is targeted. The description adds no value beyond the schema's field names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Reset') and the resource ('a scene item's position, scale, and rotation'), and specifies 'to default', which distinguishes it from setter tools like streamlabs_set_scene_item_transform. This is a specific and unambiguous purpose.
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 implies the tool should be used when reverting a scene item's transform to defaults, but it provides no explicit 'when to use' vs 'when not to use' guidance or references to alternatives like set_scene_item_transform. The context is clear enough for a simple reset operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden. It only states the action without disclosing mutations, reversibility, prerequisites, or effects on the scene item's transform. No mention of whether the flip toggles or persists, or any side effects on other properties.
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 concise sentence that immediately conveys the core action. No filler or redundancy; front-loaded with the verb and direction.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool action is simple, the description is extremely sparse given no annotations, no output schema, and no parameter explanations. It lacks any context about prerequisites, usage scenarios, or how this relates to sibling transform tools, making it incomplete for a 3-required-parameter mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 3 required parameters with no descriptions (0% coverage). The description does not explain the roles of sceneId, sceneItemId, and sourceId or how they are used to identify the target item. It fails to compensate for the missing schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (flip), the resource (scene item), and the direction (vertically), which distinguishes it from the sibling tool for horizontal flip (streamlabs_flip_scene_item_x). The verb and resource are specific and unambiguous.
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 indicates the tool flips a scene item vertically, but provides no explicit guidance on when to use this versus alternatives like streamlabs_flip_scene_item_x, rotate, or transform tools. Usage is only implied by the vertical direction, with no exclusions or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states the action 'mark as read' without mentioning idempotency, side effects, required permissions, or behavior when the notification does not exist or is already read. The description adds little beyond the name itself.
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, clear sentence with no wasted words. It is front-loaded with the action and target, making it easy to scan. Under-specification is a completeness issue, not a conciseness issue.
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?
The tool has only one parameter, no annotations, and no output schema, so the description must carry the full contextual burden. It fails to mention any side effects, return behavior, or relationship to sibling notification tools. The description is barely more informative than the tool name and leaves the agent with significant ambiguity about invocation requirements.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the parameter. It only says 'by id,' which vaguely references notificationId but does not explain its format, how to obtain it, or any constraints. The schema already defines the parameter name and type, and the description adds marginal value.
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 ('Mark') with a precise resource ('a single notification as read') and specifies the scope ('by id'). This clearly distinguishes it from the sibling tool streamlabs_mark_all_notifications_read, which marks all notifications.
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, no mention of prerequisites (e.g., obtaining the notificationId via streamlabs_list_notifications), and no exclusions. The intended usage must be inferred entirely from the tool name and minimal description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It only says 'rotate' without clarifying whether the rotation is absolute or relative, whether it overwrites the current rotation, or any side effects. This is insufficient for a mutation operation.
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, focused sentence with no unnecessary words. It is appropriately concise and immediately communicates the core action.
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 with four required parameters, no annotations, and no output schema, the description is drastically under-specified. It doesn't explain what identifiers are needed, how degrees behaves, or what the expected outcome is, leaving critical gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter semantics. It only mentions 'degrees' in passing and fails to explain the role of sceneId, sceneItemId, or sourceId. The meaning of 'degrees' itself (e.g., clockwise, relative) is not elaborated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool rotates a scene item by a given number of degrees, using a specific verb and resource. It distinguishes itself from sibling tools like set_scene_item_transform or flip, as it specifically addresses rotation by degrees.
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 tool versus alternatives, such as using set_scene_item_transform for full transform control. The description doesn't mention any exclusions or typical scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only restates the tool name. It does not explain effects (e.g., whether the buffer is discarded), required state (e.g., must be recording), or error conditions. This is essentially tautological.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that is appropriately sized for a simple zero-parameter action. However, it is so brief that it provides no additional context beyond the name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool is simple, the description lacks necessary behavioral context such as the outcome of stopping the replay buffer, whether it affects recording, or when it should be used. Given no annotations and no output schema, this is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description does not need to explain parameter semantics. The baseline of 4 is appropriate given no parameters exist.
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 'Stop the replay buffer' uses a specific verb and resource, clearly distinguishing it from sibling tools like 'start_replay_buffer' and 'save_replay'. It accurately states the action without ambiguity.
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, such as 'save_replay' or 'toggle_recording'. The description simply states the action without providing context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It mentions that the copy is independent, but does not disclose whether the original is modified, what settings are copied, permissions needed, or what the function returns. The minimal wording leaves key behavioral traits unexplained.
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, concise sentence that front-loads the action and object. Every word earns its place, with no redundant or vague phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool, the description covers the core purpose but misses important contextual details such as what happens after duplication (e.g., location of new copy, naming, return value). The absence of an output schema makes this gap more significant, but the tool's simplicity keeps it at a minimal viable level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter, sourceId, with no description and zero coverage. The description does not explain that sourceId is the ID of the source to duplicate, nor does it add any detail about the parameter's purpose or constraints. The parameter name is self-explanatory, but the description offers no additional semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Duplicate') and the resource ('a source'), and specifies that the result is a new independent copy. This is specific and distinguishes it from sibling tools like create_source, since none of the siblings handle duplication.
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 gives no guidance on when to use this tool versus alternatives such as create_source or clone-like operations. It only restates the action without providing context, exclusions, or alternative scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 states the main effect (removing all items) but does not disclose whether the sources are deleted or just unlinked, whether the action is reversible, or any side effects. For a destructive operation, this is a notable gap.
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, front-loaded sentence with no unnecessary words. It conveys the action, target, and outcome 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?
For a simple tool with one parameter, the description covers the core action but leaves ambiguities (e.g., whether sources are destroyed or just removed) and does not mention return value or failure behavior. Given the lack of annotations and output schema, more detail would be expected, but the tool's simplicity keeps it from being severely inadequate.
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 single parameter sceneId is not described in the schema (0% schema description coverage). The description implies that sceneId identifies the scene to clear, which adds minimal context, but it does not specify the format, source, or any constraints beyond the schema's type string. This partially compensates but remains thin.
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 ('Remove') and resource ('all items (sources) from a scene'), with an outcome ('leaving it empty'). This clearly distinguishes it from sibling tools like streamlabs_remove_scene (delete the entire scene) or streamlabs_remove_scene_item (remove a single item).
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 this tool versus alternatives. While the action is clear, the description does not mention exclusions (e.g., not for removing a single item) or alternatives such as streamlabs_remove_scene_item. Usage context is only implied by the name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It states the key behavior of preserving aspect ratio, which is important. But it lacks details about side effects, such as whether the position is also changed, or if the operation is destructive. The description does not contradict any annotations because none are present.
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, focused sentence that begins with the action verb and includes the essential qualifier about aspect ratio. There is no fluff or redundant information, making it highly concise and well-structured.
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?
The tool has three required parameters with no schema descriptions, no annotations, and no output schema. The description explains the core action but does not clarify parameter roles, return values, or edge cases like whether the item is scaled up or down. This is a mutating operation with significant gaps in contextual info, making it incomplete for an agent to fully understand the invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the tool description does not explain any of the three parameters (sceneId, sceneItemId, sourceId). The description adds no meaning beyond the parameter names, which are already visible in the schema. Since coverage is low, the description was expected to compensate, and it fails to do so.
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 action, 'Resize a scene item to fit within the canvas while preserving aspect ratio', which clearly identifies the resource (scene item) and the intent (fit without distortion). This distinguishes it from sibling tools like 'streamlabs_stretch_scene_item_to_screen' which implies a different scaling behavior.
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 context is implied by the description: use when you want to fit a scene item to the canvas without distorting it. However, it does not explicitly state when-not to use or mention alternatives, such as the stretching tool. The guidance is implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 does not disclose what happens for invalid IDs, what 'details' includes, or any error behavior. The read-only nature is implied by 'Get' but not 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no fluff. Every word contributes to the 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?
For a simple one-parameter read tool, the description is minimal but reasonably adequate. However, without an output schema or annotations, it would benefit from explaining what 'details' are returned and any side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must clarify the param. 'by id' adds meaning that sourceId is an identifier, differentiating it from name-based tools, but does not elaborate on format, provenance, or how to obtain the ID.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get details') and the resource ('a single source by id'). It distinguishes from siblings like streamlabs_list_sources and streamlabs_get_sources_by_name by specifying the id-based lookup.
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 tool versus alternatives like streamlabs_get_source_settings or streamlabs_get_sources_by_name. The description implies use when you have a sourceId, but does not offer exclusions or comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It clearly states the primary behavior (stretch to fill, ignoring aspect ratio), but does not mention any side effects, prerequisites, or whether other transform properties are affected. This adds context beyond the tool name but lacks depth.
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, front-loaded sentence that is direct and free of any unnecessary words. Every part earns its place by conveying the exact purpose and the key exception (aspect ratio).
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?
The tool has three required parameters, no output schema, and no annotations. While the operation itself is simple, the description does not clarify the relationship between sceneItemId and sourceId, nor how to obtain these IDs. It is sufficient only if the agent already understands the domain, leaving gaps for a general-purpose assistant.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero description coverage for its three parameters (sceneId, sceneItemId, sourceId), and the description provides no additional meaning for any of them. The description fails to compensate for the lack of parameter documentation, leaving the agent to rely on names alone.
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 ('Stretch') with a clear resource ('scene item') and outcome ('fill the entire canvas'), and notably clarifies that it ignores aspect ratio. This distinguishes it from the sibling tool fit_scene_item_to_screen, which would preserve aspect ratio.
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 implies the use case: stretch an item to fill the canvas without preserving aspect ratio. However, it does not explicitly contrast it with the fit tool or provide guidance on when to choose one over the other, leaving usage context only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 only states the action without explaining what happens after disabling, whether it is reversible, any side effects, or the relationship to the active scene.
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 sentence with no extraneous words. It is front-loaded and appropriately sized for a simple action, demonstrating excellent conciseness.
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 zero-parameter tool with no output schema, the description is mostly complete. However, it could benefit from a note about the expected state change or how it fits into the studio mode workflow, but it is not severely lacking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema already covers this completely (100% coverage). Since there are no parameters to describe, the baseline of 4 applies, and the description does not need to add parameter-specific details.
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 the specific verb 'Disable' and names the resource 'studio mode', making the function unambiguous. It clearly distinguishes from sibling tools like streamlabs_enable_studio_mode and streamlabs_get_studio_mode_status.
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 about when to use this tool versus alternatives. It does not mention any prerequisites, scenarios, or reasons for disabling studio mode, leaving the agent to infer usage solely from the action name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 only states what the tool does, not what the response contains, whether it might error (e.g., when studio mode is off), or any side effects. This is a significant gap for an unannotated tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, straightforward sentence with no unnecessary words. It is front-loaded with the action and target, making it highly concise.
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?
This is a simple getter with no parameters or output schema, so the description is somewhat adequate. However, it is ambiguous about what 'studio mode / transitions state' includes and does not describe the return format, which could leave an agent uncertain about how to interpret the result. More detail would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, and the input schema is empty. Since there are zero parameters, the description has no parameter details to add, and the baseline of 4 applies.
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 'Get the current studio mode / transitions state' clearly identifies the action (get) and the resource (studio mode/transitions state). It distinguishes itself from sibling tools like enable/disable/execute studio mode by using 'get' as the verb, though it doesn't explicitly name alternatives.
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 implies it is used to read the current state, but provides no explicit guidance on when to use this tool versus the enable/disable/execute sibling tools. It doesn't mention any prerequisites or scenarios where this would be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose mutation effects; it only says 'Update' without specifying whether settings are replaced wholesale, whether validation occurs, or any permissions/error behavior, leaving the agent to infer the consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The entire description is one sentence with examples, front-loading the action and using no filler; every word contributes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the open-ended 'settings' object, no annotations, and no output schema, the description lacks guidance on discovering valid settings keys per source type, whether an update merges or replaces, and what errors might occur, making it incomplete for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds value by showing example keys for 'settings' and mapping them to source types, but it never explains 'sourceId' (though the name implies it) and does not cover the full semantics of arbitrary settings objects, leaving much to the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Update' with the resource 'settings/properties for a source', and provides concrete examples (browser_source URL, text_gdiplus text) that clarify scope and differentiate it from read-only siblings like streamlabs_get_source_settings.
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 examples ('{ url: ... } for a browser_source, or { text: ... } for text_gdiplus') imply relevant contexts, but the description does not explicitly state when to prefer this tool over alternatives or mention excluded cases, such as using get_source_settings to read current values first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. 'List' implies a read operation, but the description does not disclose what is returned (e.g., source names, IDs, mute/volume states) or whether it returns scene items. This is minimal behavioral detail for an unannotated tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word contributes to the core meaning, making it easy to parse quickly.
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 list tool, the description is adequate but not complete. It does not describe the return format (no output schema exists), and the ambiguous sibling names (list_audio_sources, list_all_audio_sources) suggest that some additional context about scene-scoping would improve completeness. Overall it is minimally viable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain the parameter. It does so minimally by saying 'by id', which maps sceneId to the scene's identifier, but it lacks guidance on where to obtain the id or any format constraints. This is just enough to disambiguate the parameter.
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 a clear resource ('audio sources') and scope ('for a specific scene by id'). It distinguishes from siblings like streamlabs_list_audio_sources by making clear this is scene-scoped, and the parameter name sceneId reinforces that.
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?
Usage context is implied: use this when you need audio sources for a specific scene and have the scene id. However, there is no explicit guidance on when to prefer this over streamlabs_list_audio_sources or streamlabs_list_all_audio_sources, nor any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only states the operation and ID sourcing, without mentioning side effects, error handling, reversibility, or any impact on other scene items. The description adds minimal behavioral insight beyond what the name implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary purpose and followed by a helpful usage hint. There is no redundant text, making it highly concise and well-structured.
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 with 4 required parameters, no output schema, and no annotations, the description is too sparse. It fails to explain the role of sourceId, the semantic distinction between the IDs, or what happens on success/failure. The active-scene pointer is useful but insufficient for a complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description must compensate. It explains where to get sceneId and sceneItemId, and 'visible' is implied by 'show or hide', but sourceId is completely unexplained. The relationship between sceneId, sceneItemId, and sourceId is also not clarified, leaving a significant semantic gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Show or hide a scene item') and distinguishes it from sibling scene item operations like transform or scale. It also provides a pointer to obtain the required IDs from streamlabs_get_active_scene, 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.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the user to get sceneId and sceneItemId from streamlabs_get_active_scene, providing a clear context and prerequisite for using the tool. It does not explicitly mention when not to use it or alternative tools, but the active-scene context and operation purpose implicitly guide usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only describes the high-level action and does not mention potential side effects (e.g., whether the source is removed from its current scene), error conditions (e.g., invalid scene/source id), or the default placement of the new scene item. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the verb and resource. It contains no redundant information and earns its place by conveying the essential purpose and a key usage hint. Excellent conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is complete enough only for a trivial read tool. For a mutation tool, it fails to cover important aspects such as how to obtain sceneId, error behavior, and any side effects. The existence of many sibling tools further increases the need for clearer context, which this description does not provide.
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 two bare string parameters with no descriptions, so the description must compensate. It does clarify that sourceId comes from streamlabs_list_sources and represents an existing source, but it does not explicitly map sceneId to a source list (e.g., streamlabs_list_scenes) or explain how the ids are structured. The description adds partial meaning but leaves gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does: adds an existing source to a scene as a new scene item. It specifies the verb ('Add'), the resource ('existing source'), the target ('scene'), and the result ('new scene item'). It also differentiates from sibling tools like create_and_add_source by explicitly noting the source is existing and identified by id.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context: 'by id, from streamlabs_list_sources' tells the agent where to obtain the sourceId. It implies using an existing source rather than creating a new one, which helps with tool selection among siblings. However, it does not explicitly mention the sceneId source (e.g., streamlabs_list_scenes) or provide exclusions such as 'do not use if you need a new source'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 only says 'Get' and gives examples, but does not disclose behavior such as whether the sourceId must exist, error handling, authentication requirements, or the structure of the returned settings object. This lack of behavioral detail is a significant gap for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, with a clear main statement followed by helpful examples. Every part earns its place, and there is no irrelevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with one parameter, the description provides a basic understanding and examples of what 'settings' might include. However, without an output schema, it does not describe the return format or handle edge cases. The examples give some context, but the description remains minimal for a tool with no annotations and no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the parameter meaning. It does not explain what sourceId is or how to obtain it (e.g., from streamlabs_list_sources). The parameter name is self-descriptive to a degree, but the description adds no value beyond the schema, leaving the agent without guidance on how to populate sourceId.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'settings/properties for a source', with concrete examples (URL of a browser source, file path of a media source). This distinguishes it from sibling tools like streamlabs_get_source, which likely returns general source info, by focusing on settings/properties.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when you need current settings/properties of a source, providing clear context. It does not explicitly mention alternatives or exclusions, but the purpose is unambiguous. Examples clarify the type of settings returned, so the intended usage is reasonably clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It correctly implies a read-only operation (getting status) and hints at the return being a status string. However, it does not disclose whether the status is for both streaming and recording simultaneously, how often it updates, or whether it can fail (e.g., when not connected). Still, for a simple getter, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the tool's purpose and provides a clear example list of possible statuses. Every word earns its place; no filler or 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?
Given the tool's simplicity (0 params, no output schema, no annotations), the description is mostly complete. It tells the agent what the tool returns (status). However, it does not specify the exact return format (e.g., a string vs. an object with streaming and recording booleans), and there is no output schema to fill that gap. A slightly more explicit note about response shape would elevate completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema coverage is 100%. The description adds meaning by explaining what the returned status represents (streaming/recording state, with example values). Since there are no parameters to describe, the description appropriately focuses on the output semantics, which is useful for the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: getting current streaming/recording status, with a specific verb ('get') and resource ('streaming/recording status'). It also lists example statuses ('offline, starting, live, ending, etc.'), which adds clarity. However, it does not explicitly distinguish it from sibling tools like streamlabs_toggle_streaming, though the name already conveys a read-only intent.
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 implies when to use this tool (to check streaming/recording status) but does not provide explicit guidance on when not to use it or mention alternatives like streamlabs_toggle_streaming. The absence of parameters and the read-only nature make usage fairly self-evident, but there is no explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. It states the basic action but does not disclose any side effects, reversibility, or scope limitations (e.g., whether this permanently clears the unread count or applies only to the current user).
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, front-loaded sentence with no wasted words. It is optimally concise and immediately understandable.
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 zero-parameter, state-changing tool, the description is largely complete. It does not explain return values, but no output schema exists and the operation is self-evident. Slight ambiguity about the exact scope ('all notifications' could mean all in the system) is mitigated by the tool name.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is empty with 100% coverage. The baseline for zero parameters is 4, and no parameter-level explanation is needed since there are none to describe.
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 ('mark') and resource ('all notifications') with a clear target state ('as read'). It explicitly distinguishes itself from the sibling tool streamlabs_mark_notification_read by indicating the bulk scope ('all').
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 tool versus alternatives. It does not mention the existence of streamlabs_mark_notification_read for individual notifications or any context for bulk operations, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. It merely restates the tool name without adding context about return format, side effects, or operational characteristics. Since 'get' implies a read operation, but no additional behavioral details are given, the transparency is limited.
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, front-loaded sentence that states the action and object with no unnecessary words. It is appropriately concise for a zero-parameter tool.
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 (no parameters, no output schema, no annotations), the description adequately conveys the essential purpose. It lacks explicit return-value details, but the complexity is low, and the name plus description suffice for basic usage. A perfect score would require more context, but 4 is appropriate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description does not need to add parameter semantics, and the empty input schema aligns perfectly with the simple getter behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to get the currently loaded scene collection. The verb 'Get' and resource 'scene collection' are specific, and 'currently loaded' distinguishes it from sibling tools like streamlabs_list_scene_collections, which lists all collections.
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 implies usage: use this tool when you need the active scene collection rather than a list of all collections. However, it does not explicitly mention alternatives or provide exclusion criteria, leaving the guidance to inference from the tool name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses a critical behavioral trait: only provided fields are changed, leaving others untouched. This patch-style partial update is not apparent from the schema alone, as the schema only marks fields as optional without stating that omitted ones are preserved.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the action, and every word earns its place. The second sentence provides an essential usage note without any filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 parameters and nested objects, the description covers the core action and partial-update behavior but omits details like coordinate/unit conventions and when to choose this over more specific transform tools. The absence of annotations and output schema increases the burden, so more context would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only lists property names without explaining units, coordinate systems, or value meanings. It does add the partial-update semantics, but it fails to compensate for the missing schema descriptions, leaving parameter meaning vague.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as setting transform properties (position, scale, crop, rotation) on a scene item, using the specific verb 'Set'. It directly distinguishes itself from single-purpose siblings like set_scene_item_scale and rotate_scene_item by mentioning the full set of transform fields.
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 'and/or rotation' and 'Only pass the fields you want to change' imply the tool is for partial updates and general property setting. However, it does not explicitly reference alternatives or state when to prefer this over single-purpose sibling tools, so guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'Open/focus' conveys that the tool performs a non-destructive UI focus action, but it does not disclose potential side effects (e.g., whether it brings the panel to front, requires the app to be running, or fails silently if the panel is already open). This is acceptable for a simple UI action but not richly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with only ten words. It is perfectly concise and front-loaded: the verb 'Open/focus' appears immediately, and the resource is specified clearly. No filler or redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, no output schema, and a simple UI action, the description is largely complete. However, it could briefly mention that the Streamlabs Desktop app must be running or that the action is idempotent, which would make it more robust. Still, for this complexity level, it suffices.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the baseline is 4. The description does not need to explain parameter semantics, and indeed the schema is empty. The description adds no parameter information, which is fine given there are none.
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 the specific verb 'Open/focus' and names an exact resource: 'the notifications panel in the Streamlabs Desktop UI'. This clearly distinguishes it from sibling tools like streamlabs_list_notifications or streamlabs_mark_notification_read, which operate on notification data rather than the UI panel.
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 gives no guidance on when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites. While the purpose is clear, the agent is left without explicit context on when this UI action is appropriate compared to the many notification-related siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. It explains the high-level operation but omits critical details such as whether the scene must already exist, what happens on invalid source types, how errors surface, or whether the operation is reversible. For a mutating action with zero annotation coverage, this 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first states the core purpose, the second provides practical type examples. No filler or redundancy, making it easy to scan and understand.
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 4 parameters, a nested settings object, no annotations, and no output schema, the description covers the primary purpose and type examples adequately. However, it misses explicit differentiation from sibling tools (create_source, add_source_to_scene) and lacks guidance on prerequisites or failure behavior, leaving the agent to infer these from surrounding context.
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 description enriches the `type` parameter by listing common source types with human-readable labels (e.g., 'dshow_input' (webcam), 'ffmpeg_source' (media)), going beyond the schema's single example. It does not add much for `sceneId` or `settings`, but schema coverage is 75%, so the baseline is 3 and the extra type list pushes it higher.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create a brand new source and add it to a scene in one step'), identifying the specific verb, resource, and atomicity. It also lists common source types, which helps distinguish this combined tool from siblings like streamlabs_create_source and streamlabs_add_source_to_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?
The phrase 'in one step' clarifies that this tool combines creation and addition, which is useful context when choosing among siblings. However, it does not explicitly name alternatives or state when NOT to use this tool (e.g., if you only need to create a source or only add an existing one), so it stops short of fully explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden of behavioral disclosure. It only states the action and 'empty', but fails to mention what happens when a scene with the same name exists, whether the scene becomes active, or any prerequisites. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, front-loaded with the action, no filler or redundancy. Perfectly sized 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?
For a single-parameter create tool with no output schema, the description covers the core action but omits edge-case behavior like duplicate name handling and side effects. It is minimally viable but has clear gaps.
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 description includes 'with the given name', directly explaining the sole 'name' parameter. Since the schema provides no description for this parameter, this adds meaningful semantic context beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Create a new (empty) scene'. This clearly distinguishes it from sibling tools like streamlabs_list_scenes or streamlabs_rename_scene, and the qualifier 'empty' clarifies exactly what is created.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies the tool is for creating a new scene by name, which is the only sensible use case among siblings. It does not explicitly state alternatives or exclusions, but for a simple creation tool the context is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the full burden. It discloses the precondition but fails to mention failure modes (e.g., not in studio mode), return values, or whether it's a mutating action (obvious but not stated). No annotation contradiction.
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?
One concise sentence, front-loaded with the important information, no unnecessary words.
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?
Despite low complexity, the description lacks details on error handling, return value, and behavior when studio mode is off. Since there's no output schema or annotations, these gaps are notable, but the core action is sufficiently described for a simple use case.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is empty. The description implicitly handles the absence of arguments, and no parameter documentation is needed; baseline for zero params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('push the currently previewed scene live') and specifies the context ('while in studio mode'), distinguishing it from sibling tools like switch_scene and studio mode toggles.
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?
It provides a clear precondition ('while in studio mode') and implies the tool is for transitioning, not direct switching. However, it doesn't explicitly name alternatives or exclusions, so it's good but not perfect.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. The verb 'List' implies a read-only operation, but the description does not explicitly state that it does not modify notification read state, nor does it address the interplay between onlyRead and onlyUnread (e.g., mutual exclusivity). This leaves some ambiguity about side effects.
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, front-loaded sentence that states the primary action and optional filters without any redundant wording. It is efficient and easy to parse, earning a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with three optional parameters and no output schema or annotations. The description covers the core purpose but leaves gaps: it does not explain default behavior when no filters are applied, the exact return format, or how conflicting filters (onlyRead and onlyUnread) are handled. For a list tool, these are not deal-breakers but would improve 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?
Schema coverage is 100%, so each parameter is already fully documented in the input schema. The description's mention of 'type and read state' adds no meaning beyond the schema's parameter descriptions. It simply rephrases them at a high level, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the verb 'List' and the resource 'Streamlabs Desktop's in-app notifications', making the tool's purpose explicit. It also mentions optional filters, which distinguishes it from sibling tools like mark_notification_read or push_notification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by indicating it lists notifications and can be filtered. While it does not explicitly name alternative tools, the verb 'List' and the optional filters clearly communicate when to use this tool versus mutating or panel commands. The absence of explicit exclusions is acceptable given the simplicity of the operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 of behavioral disclosure. It implies a state-changing effect ('Switch') but does not disclose potential side effects, error behavior, required permissions, or what happens to the current scene/collection. This leaves the agent with limited information about the tool's runtime 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?
The description is a single, front-loaded sentence that wastes no words. It states the action, the resource, and the parameter source in a concise manner.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool, the description covers purpose and parameter source adequately. However, with no annotations and no output schema, it leaves gaps around return values, error handling, and post-conditions. These would be helpful for an agent to fully understand the tool's 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?
The schema only provides the parameter name 'collectionId' with type 'string' and no description. The description compensates by explaining that the parameter is the scene collection id and instructs the agent to retrieve ids via streamlabs_list_scene_collections. This adds meaningful context beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Switch' and clearly identifies the resource as 'scene collection', with the method 'by id'. This clearly distinguishes it from sibling tools like streamlabs_get_active_scene_collection (read) or streamlabs_create_scene_collection (create).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states when to use the tool: when you want to switch to a different scene collection. It also provides a concrete pointer to streamlabs_list_scene_collections for obtaining valid ids. However, it does not explicitly mention when not to use it or name alternative tools for related tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosure. It clarifies what 'refresh' means via examples but does not address side effects (e.g., interruption of playback), prerequisites, or error behavior. This is a moderate level of transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action, and contains no redundant wording. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description adequately covers purpose and usage. It lacks details about return values or error handling, but the examples and use case make it reasonably complete for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter (sourceId) with no description (0% schema coverage). The description does not mention sourceId at all or explain how to identify the source, leaving the parameter meaning to rely solely on its name. The description fails to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Refresh a source') and provides concrete examples ('reload a browser_source's page, or a media source's file'), making it distinct from sibling tools like list_sources, update_source_settings, or rename_source.
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?
It gives a clear use case ('Handy for forcing an overlay to reload'), which implies when to use it. However, it does not explicitly mention alternatives or exclusions, so guidance is present but less formal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 of behavioral disclosure. It states the mutation ('Switch') but does not explain potential side effects (e.g., changing the active scene may interrupt current streaming), error behavior for invalid scene ids, or whether the operation is asynchronous. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence. It front-loads the action and includes the essential supplementary information (where to get ids). Every word earns its place; there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with no output schema, the description covers the core operation and parameter sourcing. However, it omits any mention of return values, success/failure behavior, or prerequisites (e.g., Streamlabs Desktop must be running). This is a clear gap for an agent that needs to know what to expect after calling the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the single parameter sceneId clearly with 100% coverage. The description adds value beyond the schema by telling the agent where to get valid ids (streamlabs_list_scenes), which is practical semantic guidance. This goes beyond the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Switch Streamlabs Desktop to a different scene') and specifies the resource (a scene identified by its id). It distinguishes this tool from siblings like get_scene or get_active_scene by focusing on the act of switching. The reference to streamlabs_list_scenes reinforces the specific operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool (to switch scenes) and explicitly tells the agent how to obtain valid scene ids via streamlabs_list_scenes. It does not mention exclusions or alternative tools, but the usage context is clear enough for an agent to select it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It clearly states the side effect of switching to the new collection, which is a useful behavioral disclosure. However, it omits potential edge cases (e.g., behavior if a collection with the same name exists) and does not describe permissions or reversibility, leaving some gaps.
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, front-loaded sentence with no filler. It conveys the action, the resource, the initial state (empty), and the side effect (switch) in 14 words, earning every word's place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter create tool with no output schema and no annotations, the description covers the core purpose, the parameter, and the switching side effect. It is sufficiently complete for the tool's simplicity, though a note on duplicate-name behavior would push it to 5.
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 schema has one parameter (name) with 0% coverage, so the description must add meaning. The phrase 'with the given name' explicitly maps the parameter to its purpose, making it clear that the name is used for the new scene collection. This compensates for the schema's lack of description.
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 specifies a concrete verb ('Create') and resource ('scene collection'), with clear qualifiers ('new, empty') and a distinct behavioral outcome ('switch to it'). This differentiates it from related tools like create_scene (creates a scene, not a collection) and load_scene_collection (loads an existing one).
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 implies usage (when you need a new empty scene collection and want to switch to it), but it does not explicitly mention alternatives or conditions when this tool should be preferred. No disambiguation against load_scene_collection or create_scene is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the key behavioral trait (non-unique names may return multiple results), which is valuable. However, it does not mention return format, error behavior, or whether it returns full source objects, leaving some ambiguity for the agent.
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 one concise sentence (15 words) that is fully front-loaded with the core purpose and the critical caveat about multiple results. There is 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?
For a simple single-parameter lookup with no output schema, the description covers the essential non-obvious behavior (possible multiple results). It doesn't elaborate on return structure or edge cases, but given the low complexity and sibling tools that imply source objects, it is sufficiently complete for selection and basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It adds semantic meaning by specifying 'display name', clarifying that the 'name' parameter is the user-facing name, not an ID. However, it lacks details like case sensitivity, exact matching, or whitespace handling, so it only partially compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds sources by their display name, with a specific verb ('Find'), resource ('sources'), and method ('by their display name'). It distinguishes itself from siblings like streamlabs_get_source (likely by ID) and streamlabs_list_sources (all sources) by emphasizing the by-name lookup and the non-uniqueness caveat.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context that the tool should be used when looking up sources by display name, and the warning about multiple results implies it is not suitable when a unique source is expected. It doesn't explicitly name alternatives, but the sibling tool names fill that gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It clearly implies a read-only operation ('List all scenes') but does not disclose return format, ordering, pagination, or whether scenes include sources. This is minimal but not misleading.
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, focused sentence with no filler. It front-loads the action and object, making it immediately scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with no parameters and no output schema, the description is sufficiently complete. It specifies the scope ('current scene collection') and the action ('list all scenes'). However, it could mention the expected return type (e.g., array of scenes) to further guide the agent, so not a perfect 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is empty. The description does not need to explain parameters. Per the rubric, 0 params receives a baseline of 4, and there is nothing to add beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('scenes'), clearly indicating it retrieves all scenes in the current scene collection. It distinguishes itself from siblings like 'streamlabs_get_scene' (specific scene) and 'streamlabs_get_active_scene' by explicitly saying 'all scenes'.
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 implies usage context ('current scene collection') but does not explicitly state when to prefer this over alternatives or provide exclusions. An agent could infer it is for enumeration, but there is no direct guidance about when to use 'get_scene' vs 'list_scenes'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description clearly indicates this is a read-only list operation, which is the primary behavioral trait. However, with no annotations provided, it does not add any extra context (e.g., whether the list is paginated, whether it includes hidden sources, or return format specifics). It is sufficient for a simple list but lacks depth.
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, front-loaded sentence with no wasted words. It efficiently conveys the tool's purpose and scope.
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 zero-parameter, read-only list tool, the description is adequate. It clearly states what is listed and the context (Streamlabs Desktop). It could mention return format or differences from similar list tools, but these are minor gaps given the simplicity.
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, so there is nothing to explain. The description correctly describes the tool's purpose without parameter ambiguity. Baseline of 4 applies because 0 params means no parameter documentation needed.
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') and a clear resource ('all sources') with examples (cameras, capture devices, audio inputs), and scopes it to 'configured in Streamlabs Desktop.' This distinguishes it from sibling tools like streamlabs_list_scenes (scenes) and streamlabs_list_available_source_types (available types), though it doesn't explicitly name them.
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 implies usage when you need an overview of all configured sources, but it does not explicitly mention alternatives or when not to use this tool. Given the existence of streamlabs_list_audio_sources and streamlabs_list_all_audio_sources, more explicit guidance on which to choose would be helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for disclosing behavioral traits. It explicitly states 'Permanently delete,' which communicates irreversibility—a critical trait. However, it omits potential side effects (e.g., whether sources attached to the scene are also deleted) and does not discuss error behavior or 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?
The description is a single concise sentence, front-loaded with the action 'Permanently delete.' It is free of redundancy and captures the core purpose efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation with one parameter and no output schema, the description adequately covers purpose, parameter, and the critical permanence aspect. It does not specify return values or error handling, but these are less critical for a destructive action where the schema and tool nature are straightforward.
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 schema has one parameter (sceneId) with no description, and schema coverage is 0%. The description adds 'by id,' which clarifies that the parameter is the scene identifier but does not elaborate on the format, source, or how to obtain it. This is a minimal but not thorough compensation for the lack of schema documentation.
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 'Permanently delete a scene by id' clearly states the action (delete), the target (scene), and the scope (by id). It distinguishes from sibling tools like list_scenes, get_scene, and create_scene by indicating it is a destructive removal 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 description implies usage for deleting a scene but provides no explicit guidance on when to use this versus alternatives, no prerequisites, and no mention of when not to use it. The sibling names help contextualize, but the description itself offers only implicit usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals a key behavioral trait: the rename propagates to all usages of the source, not just one scene item. This is valuable context beyond what a generic 'Rename a source' would convey.
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 concise sentence that delivers the key information in the first four words and adds an important caveat in parentheses. Every word earns its place with 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?
For a simple two-parameter tool with no output schema and no annotations, the description is adequate but not thorough. It explains the primary behavior and a key nuance, but lacks parameter details and explicit usage scenarios. It is minimally complete but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the parameters 'sourceId' or 'newName' beyond what the schema already indicates. The parameter names are self-explanatory, but the description doesn't add any constraints, formats, or examples, leaving the agent with minimal guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Rename a source' with a specific verb and resource, and adds the critical scope clarification that it renames the underlying source everywhere, not just one scene item. This distinguishes it from any item-level operation and gives a precise purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when you intend to rename the source globally across all scene items. It does not explicitly name alternatives or say 'use this instead of X', but the clarification 'not just one scene item' provides enough context to select it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It explains the meaning of the deflection parameter range (0 silent, 1 max/unity gain), which is helpful. However, it does not mention potential side effects, errors (e.g., invalid sourceId), or persistence of the setting.
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 sentence that is front-loaded and free of extraneous words. Every word contributes to the tool's purpose and parameter semantics.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with no output schema and no annotations, the description is largely sufficient. It covers the key behavior and parameter range. It could be more complete by mentioning error handling or prerequisites (e.g., source must be audio-capable), but these are not critical for basic use.
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 schema covers 50% of parameters (deflection has a description). The tool description adds context by clarifying that sourceId refers to an audio source and that deflection represents the fader position with a specific range. This adds meaning beyond the schema, though sourceId remains underdescribed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (set), the resource (audio source's volume fader position), and the exact range (0 to 1). It distinguishes this tool from sibling tools like set_source_muted by focusing on fader deflection rather than muting.
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 implies usage for adjusting audio source volume but does not explicitly state when to use this tool versus alternatives like set_source_muted or other audio-related tools. No exclusions or alternative guidance are provided, but the purpose is self-evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. While it states the action and its general purpose, it does not describe side effects, state changes, idempotency (if already started), error conditions, or any resource implications. This is a significant gap for a state-changing operation.
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 sentence with a helpful parenthetical clarification. It is front-loaded, concise, and every word earns its place without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple no-parameter tool, the description adequately explains the purpose and benefit. It could mention the relationship to stop_replay_buffer and save_replay, but the core functionality is clear enough. The lack of output schema and complexity lowers the demand on the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema covers everything (100% coverage). The description does not need to add parameter details, so the baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Start the replay buffer', with a specific verb and resource. The parenthetical explains the purpose ('lets you save instant replays of the last N seconds'), which differentiates it from siblings like stop_replay_buffer and save_replay.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context on when to use the tool (when you want to enable instant replay capture), but it does not explicitly mention when not to use it or name alternative tools like stop_replay_buffer or save_replay. Still, the parenthetical implies the intended workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral transparency burden. It discloses that the tool returns the scene 'with its items', which is useful. However, it does not mention error behavior if the scene id doesn't exist, return format, or any side effects (though as a getter, side effects are minimal). The description is adequate but lacks depth.
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, front-loaded sentence with no unnecessary words. It conveys all essential information 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?
The tool is simple (one parameter, no output schema), so the description covers the basics: what it does and the key input. However, it lacks details about return structure, error handling, or any prerequisites. Given no output schema and no annotations, the description is sufficient but not rich enough to fully anticipate behavior in edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does so by explaining the parameter's role: 'by scene id' clarifies that sceneId identifies the scene to retrieve. This directly adds meaning beyond the raw schema, which only lists sceneId as a required string. For a single parameter, this is decent compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get a specific scene (with its items) by scene id.' It uses a specific verb ('Get') and a specific resource ('a specific scene'), and distinguishes it from siblings like streamlabs_list_scenes (which lists all) and streamlabs_get_active_scene (which gets the active one).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the context of use: when you have a scene id and need that particular scene and its items. It is clear that this is for fetching a specific scene, not for listing or switching. However, it does not explicitly name alternatives or exclusion conditions, but the context is evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must stand alone. 'List' implies a non-destructive read operation, but no additional context is given about response format, ordering, or errors. Adequate for a trivial list.
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?
A single, clear sentence that immediately states the action and resource. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list tool with no output schema, the description is complete. It tells the agent exactly what the tool does, and the return value (a list of collections) is implied.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is empty, so the description need not explain parameter semantics. Baseline of 4 applies.
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 verb 'list' with resource 'saved scene collections' distinguishes it from sibling tools like streamlabs_list_scenes, which lists scenes. No ambiguity.
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?
Usage is implied: use when you need to enumerate all saved scene collections. No explicit alternatives or exclusions, but the simple nature and name make selection obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly discloses the key side effect: the scene item is removed but the underlying source remains. This is critical for an operation that might be mistaken for deletion. It does not mention error cases or reversibility, but for this straightforward tool, the main 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exactly two sentences. The first sentence states the main action, and the second adds a crucial clarification. Every word earns its place, with no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with no output schema, and the description covers the core purpose and the key nuance about not deleting the source. It is mostly complete, though it lacks explicit parameter guidance (e.g., why sourceId is needed when sceneItemId is present).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain what sceneId, sceneItemId, or sourceId mean beyond their names. It mentions 'scene' and 'source instance' but does not clarify how the three identifiers relate, making it hard for an agent to know which ID goes where.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (remove a scene item) and the resource (scene item from a scene), and explicitly distinguishes it from deleting the underlying source. This is a specific verb+resource definition that sets it apart from siblings like streamlabs_remove_source.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the appropriate scenario by clarifying that the underlying source is not deleted, which indirectly distinguishes it from streamlabs_remove_source. However, it does not explicitly say when to use this tool versus alternatives, such as 'use streamlabs_remove_source to delete the source entirely.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses critical behavioral traits: permanence ('Permanently delete') and the side effect of removing the source from all scenes. This adds meaningful transparency beyond 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?
One clear, front-loaded sentence with no wasted words. The parenthetical adds necessary scope without bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter delete tool, the description covers the key behavioral context (permanence, global scope). It lacks explicit parameter guidance, but overall it is sufficient for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain sourceId beyond its name. The agent must infer that it is the identifier of the source to delete, with no guidance on where to obtain it or its format.
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 ('delete') and resource ('source'), and clarifies the global scope with 'removes it from every scene it appears in,' which distinguishes it from sibling tools like streamlabs_remove_scene_item.
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?
It clearly implies when to use this tool (to delete a source across all scenes) and differentiates from per-scene removal, though it does not explicitly name an alternative like remove_scene_item.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the source is not added to any scene, which is a behavioral trait. However, it does not mention potential side effects, return values, or error conditions, but the disclosed trait is significant.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, concise and front-loaded with the main action. The parenthetical guidance about alternatives adds value without unnecessary length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description clarifies the workflow context but lacks details about settings object structure, valid source types, or expected outcomes. Given the absence of annotations and output schema, this leaves gaps, but the description is not misleading and covers the key differentiator.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not elaborate on the 'name', 'type', or 'settings' parameters. The schema covers 'type' with examples but lacks descriptions for 'name' and 'settings'. With only 33% schema coverage, the description should compensate but does not add parameter-level meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool creates a new source without adding it to a scene, which is a specific action. It also distinguishes this tool from siblings like streamlabs_create_and_add_source and streamlabs_add_source_to_scene.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent when to use this tool versus alternatives: use this to create a source standalone, then use streamlabs_add_source_to_scene afterward, or use streamlabs_create_and_add_source for both. This gives clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It explains what the tool does ('Enable studio mode') and adds context about what studio mode entails ('preview + program view'), but it does not disclose potential side effects, prerequisites, or reversibility. For a simple state-change action, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately states the action ('Enable studio mode') followed by a brief clarifying parenthetical. There is no filler or redundant detail.
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 low complexity (no parameters, no output schema), the description is sufficient to inform an agent about the action and its purpose. It lacks mention of related sibling tools, but that is not necessary for a simple enable action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is 100% vacuously, so the baseline is 4. The description adds no parameter-specific information because there are no parameters to describe.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb 'Enable' and a specific resource 'studio mode', further clarified as 'preview + program view for previewing scenes before they go live'. This distinguishes it from sibling tools like disable_studio_mode and get_studio_mode_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by explaining the purpose ('for previewing scenes before they go live'), which implies when to use it. However, it does not explicitly mention alternatives or exclusions, such as using disable_studio_mode to turn it off or get_studio_mode_status to check current state.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the side effect of writing to disk and the need for confirmation, but lacks details on prerequisites (e.g., active replay buffer), potential errors, or what happens after saving.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the primary action and followed by an important usage instruction. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 params, no output schema), the description sufficiently covers the main action and confirmation requirement. However, it omits edge-case behavior such as what occurs if no replay is available or if the buffer is inactive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is trivially 100%. The description adds no parameter details, but none are needed. Baseline for 0 params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Save'), the resource ('current instant replay from the replay buffer'), and destination ('to disk'). It distinguishes itself from related buffer management tools (start/stop replay buffer) by specifying the save operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool and includes an explicit user-confirmation requirement. However, it does not explicitly mention alternatives or when not to use it, though no direct alternatives exist among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It discloses the core behavior (mute/unmute) but does not mention side effects, reversibility, permissions, or error conditions. This is minimal but not misleading, so a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, action-oriented, and free of unnecessary words. The first sentence states the purpose; the second provides a critical prerequisite. Perfectly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter tool, the description covers the operation and how to obtain the required ID. It does not mention return values or error handling, but with no output schema and low complexity, it is reasonably complete. Minor missing context about source eligibility is not critical.
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 schema already fully documents both parameters with clear descriptions. The description adds extra value by telling the user where to get the sourceId, which is practical guidance beyond the schema. It doesn't add detail for 'muted', but the sourceId provenance is useful.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (mute/unmute) and the resource (audio source), and it distinguishes from related tools like set_source_volume. The reference to streamlabs_list_audio_sources further clarifies the intended source type, making it unambiguous.
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?
It provides explicit guidance on obtaining the sourceId from streamlabs_list_audio_sources, which is a clear 'when/how to use' instruction. However, it does not explicitly contrast with alternative tools like set_source_volume or explain when not to use it, so it falls 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. 'Start or stop' clearly communicates the two possible outcomes of a toggle, but it does not specify how the current state is determined or any side effects beyond starting/stopping. This is adequate for a simple zero-parameter toggle.
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 concise sentence, front-loaded with the core action, and contains no redundant information. It efficiently conveys the tool's purpose.
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 zero-parameter toggle without an output schema, the description sufficiently covers the essential behavior. However, it leaves room for interpretation about whether 'local recording' means something distinct from streaming or replay buffer, though the naming partially addresses this.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema coverage is 100%, so the description does not need to explain parameters. The baseline for zero parameters is 4, and no additional parameter info is necessary.
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 'Start or stop local recording.' uses a specific verb and resource, clearly indicating a toggle action on local recording. It distinguishes from siblings like streamlabs_toggle_streaming and replay buffer tools by specifying 'local recording'.
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 alternatives are mentioned. The implied usage is that this tool manages local recording, but it does not differentiate from streaming or replay buffer tools, which are present in sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. The verb 'Get' clearly indicates a read-only operation, and 'including its scene items' specifies the return content. This is sufficient for a simple getter, though it does not explicitly state side-effect-free behavior or potential edge cases (e.g., no active scene error).
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, front-loaded sentence that directly states purpose and return content. Every word earns its place; there is no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and no output schema, the description fully explains what the tool returns ('the currently active scene, including its scene items'). No additional context is necessary for this simple getter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, and the schema is empty. The description correctly implies no inputs are needed. Per the rubric, 0 parameters warrants a baseline of 4 since there is no parameter ambiguity to resolve.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get the currently active scene, including its scene items.' The verb 'Get' and resource 'currently active scene' are specific and distinguish this from sibling tools like list_scenes (list all) and get_scene (get by specific identifier).
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 implies usage when you need the active scene, but it does not explicitly contrast with sibling tools such as streamlabs_get_scene or streamlabs_list_scenes. There is no clear context for when to choose this over alternatives, though the name itself strongly suggests the appropriate scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It discloses the cross-scene scope and that it lists audio sources, which implies a read-only operation. However, it does not specify whether it includes sources not assigned to any scene or the exact return structure, leaving minor gaps.
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, well-structured sentence that front-loads the action ('List every audio source') and efficiently conveys the scope with a parenthetical clarification. There is zero wasted wording.
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 simplicity of the tool (no parameters, no annotations, no output schema), the description is largely complete. It identifies what is being listed and the cross-scene scope, but could mention the return format (e.g., array of audio sources) to be fully self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is empty, so the description is the only source of parameter-level meaning. It adds useful context by clarifying the scope ('across all scenes'), which is effectively the main behavioral parameter. A baseline of 4 is appropriate for zero-parameter tools with contextual description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List every audio source') and the specific scope ('across all scenes'), which differentiates it from sibling tools like streamlabs_list_audio_sources and streamlabs_list_audio_sources_for_scene. The verb and resource are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use this tool by pointing out it covers all scenes 'not just the currently active one'. While it does not explicitly name alternative tools, the inference is straightforward given sibling names, so it provides clear context without an explicit when-not statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey the read-only nature and what is returned. It implies read-only via 'List' and discloses that muted state is included. With zero parameters and no side-effectful behavior, this is sufficient, though it could have explicitly stated that no modifications are made.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main action and key output detail, with no wasted words. Every element contributes to understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter, no-output-schema tool, the description is mostly complete. It states the scope, the included info, and a usage hint. However, it does not describe the return format (e.g., names vs IDs) or distinguish itself from the similarly named streamlabs_list_audio_sources_for_scene, which slightly reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the description does not need to elaborate on input semantics. The baseline for zero-parameter tools is 4, and no additional parameter info is necessary.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists audio sources for the current scene and includes their muted state, which is a specific verb+resource+scope. It distinguishes from siblings like streamlabs_list_all_audio_sources and streamlabs_list_audio_sources_for_scene by scoping to the current 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?
The description explicitly advises using this tool before muting/unmuting, providing a clear context for when to invoke it. However, it does not mention alternatives or exclusions (e.g., when to use list_audio_sources_for_scene), so it earns a 4 rather than a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and discloses the dual toggle behavior. It also includes a cautionary instruction to confirm with the user, hinting at the potential impact of stopping a live stream. However, it does not mention specific side effects, permissions, or reversibility, but the confirmation instruction adds meaningful context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the core action. Every word earns its place: the first sentence defines the behavior, the second provides a critical safety instruction. No redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple toggle operation with no parameters, no output schema, and no annotations, the description covers the essential behavior and includes a confirmation requirement. It is sufficient for an agent to know when and how to invoke the tool, though it could optionally mention asynchronous behavior or potential delays.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is 100% (vacuously). According to the rubric, the baseline for 0 params is 4, and the description adds no parameter-related information because none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb and resource: 'Start streaming if currently offline, or stop it if currently live.' It distinguishes itself from sibling tools like get_streaming_status (status check) and toggle_recording by explicitly describing the streaming toggle behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to 'Confirm with the user before calling this,' which is a clear usage guideline for a state-changing action. It implies when to use the tool (when the user wants to toggle streaming) but lacks explicit alternatives or exclusions, such as suggesting get_streaming_status to check the current state first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the tool is a read-only 'Get' operation and lists the specific data points returned, giving the agent a solid expectation of what it will receive without side effects.
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?
A single sentence that front-loads the action and resource, then lists the included metrics. Every word adds value, with zero redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity—no parameters, no output schema, and no complex behavior—the description fully covers what the agent needs to know: what the tool returns. There is no missing context or ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so per the rubric the baseline is 4. The description correctly implies no inputs are needed by stating it retrieves current stats without any configuration details.
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 the specific verb 'Get' followed by the resource 'current performance stats' and enumerates the exact metrics (CPU usage, FPS, dropped frames, bandwidth, disk space). This clearly distinguishes it from sibling tools that deal with scenes, sources, or streaming controls.
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?
While no explicit alternatives are mentioned, the description makes it obvious when to use this tool—whenever current performance statistics are needed. The context is clear enough, though it doesn't state exclusions or when not to use it (e.g., for historical data).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It adds context that the list is system-specific ('on this system'), implying a dependency on local capabilities. The read-only nature is implied by 'List', though output format or error conditions are not disclosed.
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, front-loaded sentence consisting of the core function and a practical hint, with no wasted words or redundant details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only listing tool, the description fully covers what the tool does and why it is useful. The lack of an output schema is acceptable because the list output is self-evident from the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the description does not need to explain parameter semantics. According to the rubric, a zero-parameter tool receives a baseline score of 4, and no additional parameter information is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's function as listing source types available for creation, using the specific verb 'List' and resource 'source types'. It distinguishes from sibling tools like streamlabs_list_sources by focusing on available types rather than existing sources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear when-to-use context by stating it is 'useful before calling streamlabs_create_source'. However, it does not explicitly mention alternatives or when not to use, so it falls slightly 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explicitly states 'it is destructive' and 'Confirm with the user before calling this', disclosing the destructive nature and required safety step. It also reveals the default behavior when no id is given. This is solid, though it could add more (e.g., irreversibility details or error handling), but it exceeds the minimum.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action, and every word earns its place. It avoids redundancy and is efficiently structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple single-parameter destructive tool with no output schema. The description covers the essential aspects: what it does, parameter behavior, and safety confirmation. It is complete enough for an agent to select and invoke correctly without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only provides a type string with no description, and coverage is 0%. The description compensates fully by explaining that the id refers to the scene collection, and if omitted, the active one is deleted. This precisely clarifies the optional parameter's meaning and default behavior, adding significant semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Delete a scene collection by id', using a specific verb and resource, and distinguishes from siblings like create, rename, load, and list. It also adds the nuance of deleting the active collection if no id is given, 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.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: use this to delete a scene collection, either by id or the active one if id omitted. It also instructs to confirm with the user because it is destructive, which is a key usage guideline. However, it does not explicitly mention alternatives or exclusions, so it falls 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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

[![streamlabs-mcp MCP server](https://glama.ai/mcp/servers/AhmadTariq1337/streamlabs-mcp/badges/card.svg)](https://glama.ai/mcp/servers/AhmadTariq1337/streamlabs-mcp)

Score Badge

Copy to your README.md:

[![streamlabs-mcp MCP server](https://glama.ai/mcp/servers/AhmadTariq1337/streamlabs-mcp/badges/score.svg)](https://glama.ai/mcp/servers/AhmadTariq1337/streamlabs-mcp)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/AhmadTariq1337/streamlabs-mcp'

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