OBS MCP
Server Quality Checklist
Latest release: v0.2.0
- Disambiguation4/5
Most tools map cleanly to distinct OBS resources and actions, but with 148 tools there are a few easily confused groups: get_scene_list vs get_scene_collection_list, get_output_status vs get_stream_status, and trigger_hotkey_by_name vs trigger_hotkey_by_key_sequence. Descriptions are detailed and usually clarify the differences, so an agent can disambiguate with careful reading, but misselection risk is non-trivial.
Naming Consistency5/5Every tool follows a consistent verb_noun pattern in snake_case (get_input_mute, set_current_program_scene, toggle_record_pause). Even composite tools like clean_audio_input and diagnose_av_health fit the pattern. No camelCase, no inconsistent verb styles, and no random names.
Tool Count1/5148 tools is far beyond any reasonable MCP server scope and exceeds the 50+ threshold for an extreme mismatch. Even though OBS is a complex application, this quantity will overwhelm an agent's ability to select among options, making the tool set unwieldy regardless of how legitimate each individual tool may be.
Completeness5/5The tool set covers the full OBS WebSocket API surface: scenes, inputs, scene items, filters, transitions, outputs, profiles, scene collections, settings, hotkeys, media, screenshots, projectors, and custom events. There are a few minor gaps (e.g., no remove_scene_collection, no transition creation), but they are easily worked around. Core workflows like 'set up a stream, capture sources, switch scenes, record, and go live' are fully supported.
Average 3.7/5 across 147 of 148 tools scored. Lowest: 1.5/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 17 commits in the last 12 weeks
- Last stable release on
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
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
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose safety and return behavior, but it only provides a vague noun phrase. It fails to indicate that this is a read-only operation or describe the structure of the returned default settings.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence and technically concise, but it is under-specified and tautological. It does not provide meaningful information, so it fails the 'every sentence earns its place' criterion.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one required parameter, no output schema, and no annotations, the description is grossly incomplete. It lacks any information about the return object shape, valid filter kind values, or how this tool relates to other filter-related operations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has a single required parameter 'filter_kind', but the description offers no explanation of its meaning, possible values, or how it affects the result. With 0% schema description coverage, the description must compensate but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Default settings object for a filter kind.' is a noun phrase that merely restates the tool name without an explicit verb like 'get' or 'return'. It does not differentiate the tool from siblings such as get_input_default_settings or get_source_filter_kind_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus the many related filter and input tools. The description lacks any context about use cases, prerequisites, or exclusions.
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 disclosure. It only states 'Start a named output,' which reveals no side effects, error conditions, idempotency, or return behavior. An agent has no idea whether starting an already-running output fails, is a no-op, or resets the output. This is almost entirely uninformative.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short and front-loaded, with no wasted words. However, it is under-specified to the point where it adds little value beyond the tool name itself. It is not bloated, but it also does not effectively use the available space to convey necessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with a single parameter and no output schema, the description should at least explain what an 'output' is in this context, whether a named output must be pre-configured, and what happens on success or failure. Given the large set of sibling tools related to outputs (get_output_status, toggle_output, stop_output, etc.), the description is too sparse to allow reliable tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has a single required parameter output_name with 0% schema description coverage. The description's phrase 'named output' merely echoes the parameter name and does not add any concrete meaning about what format the name should take, where it comes from, or how it maps to an existing output. The description fails to compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Start a named output' clearly identifies the action (start) and the resource (output), and the qualifier 'named' indicates that a specific output identifier is required. It distinguishes from sibling tools like stop_output and toggle_output through the verb choice. However, it does not explicitly clarify what 'output' refers to in the broader context of stream/record/replay buffer outputs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use start_output versus the more specific start_stream, start_record, start_virtual_cam, or start_replay_buffer. There is no mention of prerequisites, such as whether the output must already exist or be configured. The description provides no contextual cues for an agent to decide when this tool is the right choice.
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 action and offers no information about whether the rename is destructive, whether it affects references to the filter, or if there are any side effects. The description is minimally 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with zero extraneous words. 'Rename a filter.' is maximally concise and gets straight to the point, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 required parameters and no annotations or output schema, the description is entirely inadequate. It omits essential context such as the fact that filters are attached to sources, the need to specify the source_name to locate the filter, and any uniqueness or validation constraints. The description is far too minimal for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning beyond the parameter names. While 'source_name', 'filter_name', and 'new_filter_name' are self-explanatory, there is no explanation of the relationship between them (e.g., that filter_name is the existing filter attached to source_name). The description does not compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Rename a filter.' clearly states the action (rename) and the resource (filter). It distinguishes from sibling operations like set_source_filter_settings or set_source_filter_index by focusing specifically on renaming. However, it doesn't explicitly mention 'source filter', relying on the tool name for full clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. There is no mention of prerequisites, such as the filter needing to exist, or when to prefer this over other filter operations. It simply states the action without 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, the description carries the full burden. It only states that it gets a value, with no disclosure of side effects (likely none), return behavior (e.g., what happens if scene_item_id doesn't exist), or any special conditions. 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence and is concise. However, it is perhaps too terse, lacking helpful context, but it earns points for brevity and clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 2 parameters and no output schema, the description is incomplete. It does not indicate expected return values, error conditions, or parameter specifics. The sibling tool 'set_scene_item_blend_mode' exists, but no relationship is mentioned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does 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 not explain the parameters 'scene_name' or 'scene_item_id' beyond their names, and the names alone may not be enough for an agent to understand required context (e.g., item IDs may be scene-relative). No parameter details are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get a scene item's blend mode.' clearly states the action (get) and the specific resource (scene item's blend mode). It distinguishes from the sibling tool 'set_scene_item_blend_mode' which performs the write 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/5Does 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 that it complements the setter, nor does it provide any context on when retrieving a blend mode is appropriate.
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 bears full responsibility for disclosing behavior. It only states the UI action without mentioning side effects, such as whether the input must exist, whether OBS is brought to focus, or whether any state changes occur.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of ten words, with no filler. It is appropriately sized for such a simple action, though it omits some context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool, the description covers the core action but lacks usage guidelines, parameter semantics, and behavioral transparency. Given the large sibling set and absence of annotations, this is insufficient for reliable tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no descriptions (0% coverage), so the description should explain the 'input_name' parameter. The phrase 'an input's' vaguely implies the parameter but adds no detail about format, examples, or how it is used to identify the input.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Open' and the resource 'an input's Filters dialog' with context 'in the OBS UI.' It distinguishes the target from sibling tools by naming the specific dialog type, though it does not explicitly contrast with open_input_properties_dialog or open_input_interact_dialog.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus the numerous sibling tools, including other dialog openers. There are no prerequisites, exclusions, or alternative suggestions, leaving the agent to infer usage solely from the 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 must carry the full burden of disclosure. It only restates the tool's function and gives no insight into behavioral traits like whether captions overwrite previous ones, timing, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded, with a clear one-sentence summary and a simple arg listing. No waste, though it is minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, no output schema, and only one simple parameter, the description is still incomplete—it omits context about streaming state, potential side effects, or what 'send' implies, leaving agents to infer behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, caption_text, has no schema description, and the description's 'Args' section merely repeats the title 'Caption Text' without adding format, length, or encoding details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Send'), the object ('CEA-608 caption text'), and the destination ('over the live stream output'), distinguishing it from other tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, prerequisites (e.g., active stream), or alternatives. The description simply states the action without contextual 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 full responsibility for behavioral disclosure. It only states the core action, with no mention of side effects, permissions, state considerations, or return behavior. For a mutation tool, 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no filler or redundant information. It is appropriately sized for a simple setter and is front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but the description fails to differentiate it from the nearly identical sibling toggle_input_mute. This distinction is critical for an agent to correctly choose between tools. It also provides no information about return values or error conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add meaning to the parameters. It does not explain that input_muted=true means 'muted' or that input_name identifies the specific input. The schema titles provide some inherent clarity, but the description adds no value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Mute or unmute an input' clearly states the action and target resource. It is concise but does not distinguish itself from the sibling tool 'toggle_input_mute', which could cause confusion about whether this sets a specific state or toggles.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 the sibling 'toggle_input_mute' or 'get_input_mute'. It does not mention that this tool sets an explicit muted state, which is important for correct tool selection.
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 full responsibility for behavioral disclosure. It only says 'call a request' without describing side effects, potential for arbitrary actions, error behavior, or safety concerns. This is a significant gap for an inherently opaque vendor-call 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, uses a clear list format for parameters, and is front-loaded with the main action. Every sentence adds value without unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks critical context such as where to find vendor documentation, how request_data is structured, potential side effects, or whether the operation is safe. With no annotations and no output schema, the description is insufficient for an agent to fully understand the tool's behavior and risks.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description's 'Args' section adds brief explanations for each parameter (vendor_name, request_type, request_data). While helpful, the explanations are minimal and somewhat tautological (e.g., 'The vendor's request type to call'), and do not fully compensate for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Call a request registered by a third-party OBS plugin/script vendor') with a clear resource (vendor request). It does not explicitly differentiate from sibling tools, but the vendor-specific scope makes it distinguishable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives, such as standard OBS requests. The description does not mention that this is for vendor-specific extensions not covered by other endpoints, leaving usage context unstated.
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 implies a read-only operation via the verb 'get', but does not mention error conditions (e.g., unknown output name), permission requirements, or any side effects. The minimal wording adds little beyond the function 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no unnecessary words. It is front-loaded with the action and resource, making it easy to process quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with one parameter and no output schema, the description is minimally adequate: it states what the tool returns. However, it lacks details about the nature of the settings object, error handling, or how the output_name relates to outputs managed elsewhere. Given the low complexity, this is borderline sufficient but could be improved.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter (output_name) with no description coverage, so the description must compensate. It implicitly indicates that output_name is the name of the output whose settings are returned, but it does not explain valid values, how to obtain names (e.g., via get_output_list), or any format requirements. Thus it provides minimal added value over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('a named output's settings object'), clearly distinguishing it from sibling tools like set_output_settings (which writes) and get_output_status (which retrieves status rather than settings). It lacks a bit of context about what an 'output' refers to, but the purpose is 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/5Does 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 set_output_settings or get_output_status. The description only states the action without explaining use cases, 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 full responsibility for disclosing behavior. It implies a read operation but does not specify return format, error conditions, or any side effects. This is a minimal description that leaves significant ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with only two sentences and a clear argument list. Every sentence serves a purpose, though it could arguably be slightly more informative without sacrificing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with two string parameters and no output schema, the description covers the basic operation and parameter meanings. However, it does not clarify the return value structure or error behavior, which is a notable gap for a read operation with no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain parameters. It does describe realm with its two allowed values and defines slot_name as the slot to read. This adds meaning beyond the schema, but lacks details on slot semantics or value types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a value from an OBS persistent-data slot, using the verb 'Get' and specifying the resource. It implicitly distinguishes itself from set_persistent_data and other getters, though it does not 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 Guidelines2/5Does 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 get_profile_parameter or set_persistent_data. The argument descriptions are present, but there is no context about typical scenarios, 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 of behavioral disclosure, but it only lists what is retrieved without stating read-only nature, potential errors, or return format. It does not explicitly say whether the operation has side effects or what coordinate system/units are used, which are relevant for an agent invoking this 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is entirely functional and front-loaded with the verb 'Get'. It contains no redundant or extraneous words, making it highly concise and properly structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with two parameters and no output schema, the description is minimally adequate but lacks details about the return structure (e.g., exact property names, units) and error behavior. It covers the core purpose but does not fully compensate for missing annotations and output schema, leaving some ambiguity for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does 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 lack of parameter documentation. It does not explain scene_name or scene_item_id beyond implying their roles via 'a scene item's'. There is no guidance on how to obtain the scene_item_id or any format expectations, leaving the agent to infer from the parameter names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets a scene item's transform, listing specific attributes: position, scale, rotation, and crop. This is a specific verb+resource combination that distinguishes it from other getter tools like get_scene_item_enabled or get_scene_item_locked. It does not explicitly name alternative tools but the scope is clear from the listed fields.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. There is no mention of prerequisites (e.g., obtaining scene_item_id via get_scene_item_list) or exclusions. The usage is only implied by the tool being a getter, which may be sufficient for simple cases but lacks explicit direction.
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 available, the description carries the full burden of behavioral disclosure. It only states the action ('toggle') without revealing return values, side effects, prerequisites, or error conditions, which is insufficient 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler words. It is directly front-loaded with the action and target, earning its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description is still too sparse: it lacks usage guidance, parameter details, and information about return values or side effects. Annotations and output schema are absent, so the description does not provide complete contextual coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning 'input_name' has no documentation. The description also fails to clarify what constitutes a valid input name or how to reference an input, leaving the agent without necessary parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'toggle' with target 'input's mute state', clearly distinguishing it from sibling tools like get_input_mute and set_input_mute. This makes the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use toggle versus set_input_mute or get_input_mute. The description does not mention alternatives or exclusions, leaving the agent to infer usage context from sibling tool names 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?
The description mentions simulating key presses, but with no annotations it fails to disclose safety concerns, reversibility, system-wide effects, or error behavior. For an action tool, this is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and well-organized with an Args block. Every sentence contributes useful information, though the brevity leaves gaps that hurt other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an action tool with no annotations and no output schema, the description lacks return behavior, error handling, and context for choosing this over trigger_hotkey_by_name. The absence of any mention of effects or limitations makes it incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds brief meanings for all five parameters—key_id as an OBS key ID and shift/control/alt/command as modifiers to hold. Since schema coverage is 0%, this is helpful, but key_id remains an opaque reference to an external header and modifier details are minimal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool triggers a hotkey by simulating a key press plus modifiers, which is a specific verb+resource. It differentiates from the sibling trigger_hotkey_by_name by emphasizing the key sequence mechanism, though it does not explicitly name the alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus trigger_hotkey_by_name or other hotkey-related tools. It does not state prerequisites, 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.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must convey behavioral traits. It only states that it returns settings and kind, but gives no details about error handling, side effects, permissions, or what happens if the input_name is invalid. This is a simple read operation, but the description adds little beyond the basic purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of one clear sentence plus an argument definition. Every word serves a purpose, and the key information is front-loaded. It avoids unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of a single-parameter getter with no output schema, the description provides an adequate high-level summary of the return value (settings and kind). However, it lacks any mention of response structure, potential errors, or behavioral constraints, leaving some gaps for the agent regarding what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. The only parameter guidance is 'Name of the input', which merely restates the parameter name and adds no semantic value beyond the schema's own title. The description fails to clarify any constraints, formats, or default behaviors.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that it retrieves the current (non-default) settings of an input along with its kind. It uses a specific verb+resource construction and distinguishes itself from sibling tools like get_input_default_settings by explicitly saying 'non-default'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving current settings as opposed to default settings, but it does not explicitly state when to use this tool over alternatives or provide any exclusionary guidance. No mention of prerequisites or suitable contexts is included.
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 accurately describes the output (playback state, duration, cursor) without misleading claims, but it does not disclose error behavior, return format, or explicit read-only nature. For a simple getter, this is acceptable but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundant content, making it efficient and front-loaded. It could be improved with an action verb, but it succeeds in conveying the core purpose without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (one required parameter, no output schema), the description covers the essential semantics but omits return format, explicit mention of the required parameter, and error handling. This is slightly below the minimum viable completeness for a tool without annotations or an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not explicitly explain the input_name parameter. The phrase 'of a media source' indirectly hints at the parameter, but it doesn't connect it to the input schema or provide validation details, leaving the agent dependent on the parameter name alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource (media source) and the data returned (playback state, duration, cursor position). It's specific and differentiated from sibling tools like set_media_input_cursor or offset_media_input_cursor by the nature of the query, though it lacks an explicit verb like 'Gets' or 'Retrieves'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. The name implies it's the getter for media status, but the description does not state any preferred context or exclude other tools, leaving the agent to infer usage from the 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 must carry the full burden of behavioral disclosure. It only states that a dialog is opened, without mentioning any side effects, prerequisites, or UI impact, so the agent has limited understanding of the tool's 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that efficiently conveys the core action. There is no waste or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given 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 provides the core purpose but lacks usage context and behavioral details. It does not explain when to use this dialog opener versus the filter or interact dialog tools, and it omits any note about the UI impact, making it only minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one required parameter, input_name, with no description, and the description does not mention how the parameter affects the tool's behavior. Since schema coverage is 0%, the description fails to compensate by explaining the parameter's role.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Open' and clearly identifies the resource as 'an input's Properties dialog' in the OBS UI. It distinguishes from sibling tools like open_input_filters_dialog by naming the Properties dialog specifically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 such as open_input_filters_dialog or open_input_interact_dialog. The description only states what the tool does, leaving usage decisions entirely to the agent.
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 transparency burden and clearly states the mutating behavior (lock or unlock). However, it does not disclose whether the operation overwrites the existing locked state, what happens for invalid scene/item IDs, or any 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence that is front-loaded and contains no filler or redundant information. It is maximally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool is simple, the description is minimal for the context. It lacks any reference to the `get_scene_item_locked` counterpart, leaves parameter semantics unexplained, and provides no error or prerequisite context, making it insufficient for confident invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does 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 three required parameters. It only implies that a scene item is targeted, leaving `scene_name` and `scene_item_id` entirely to the schema titles, which is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb ('Lock or unlock') and a specific resource ('scene item'), so the core operation is obvious. It does not explicitly distinguish itself from sibling tools like `get_scene_item_locked`, but the verb signals a write 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/5Does 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, and does not reference the `get_scene_item_locked` sibling for reading the current locked state. It gives no context about selection or error handling.
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 transparency burden. It explicitly states the non-destructive behavior ('without removing it'), which is useful, but it does not disclose prerequisites (e.g., filter must exist), error handling, or side effects. For a simple boolean setter, this is minimally 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that clearly states the action and an important qualifier. It is appropriately sized for a simple tool and every word contributes meaning, though it is slightly under-specified in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given 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. The description gives the core action and non-destructive guarantee, but does not mention prerequisites, failure behavior, or return values. Given the simplicity, it is minimally complete but lacking in edge-case context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does 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 meaning. It only implies 'filter_enabled' via 'Enable or disable' and does not explain the roles of source_name or filter_name. The parameter names are self-explanatory, but the description adds no additional semantic value beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Enable or disable' and identifies the resource as 'a filter,' with the qualifier 'without removing it' distinguishing this from removal tools. However, it doesn't explicitly state that this applies to source filters, and it doesn't differentiate from other set operations like set_source_filter_settings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. The only hint is 'without removing it,' which differentiates from removal but doesn't help an agent choose among sibling filter tools such as set_source_filter_settings or set_source_filter_index.
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 accurately describes a read operation, but provides no additional behavioral context such as side-effect absence, required permissions, or error cases. The simple statement is not misleading, but it adds no depth beyond its literal meaning.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description must stand alone. It does not explain the return value (e.g., a boolean) or the input parameter format, leaving gaps for an agent that lacks detailed knowledge of the domain. While simple, it is incomplete for a tool with no other documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not compensate by explaining the input_name parameter. The only parameter is minimally documented in the schema as 'Input Name', leaving the agent without clarity on the expected format or examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get an input's mute state' uses a specific verb ('get') and identifies the exact resource (input mute state), clearly distinguishing it from siblings like set_input_mute and toggle_input_mute.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. The description does not mention any prerequisites, exclusions, or related tools, offering no context for an agent to decide between this and other mute-related operations.
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. It only states the return value without mentioning whether it can return null, that it's read-only, or any error conditions. The name 'get' implies safety, but the description adds no additional 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of a single short phrase that conveys the core purpose without any unnecessary words. Information is front-loaded and easily parsed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple no-parameter getter, the description adequately explains the return value. It could mention edge cases (e.g., what happens if no replay buffer exists), but given the simplicity of the tool, the description is nearly sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema covers all parameters (100% coverage). With no parameters to describe, the baseline is 4, and the description appropriately adds nothing about parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's output as the file path of the last replay buffer save, distinguishing it from sibling tools like save_replay_buffer. However, it is a noun phrase rather than a full sentence with a verb, so it's slightly less explicit about the action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does 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. There is no mention of 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 of behavioral disclosure, but it only restates the getter nature. It does not disclose error handling, return format, or edge cases, leaving the agent without crucial behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundancy. It is appropriately front-loaded and easy to parse, though it could be slightly more detailed without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read operation, the description conveys the core purpose, but it lacks details about the return value's shape and error semantics. Since there is no output schema, the description should better specify what exactly will be returned (e.g., both name and UUID? in what format?).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description does not elaborate on scene_name or scene_item_id beyond their names. It only hints that they identify a scene item, but lacks format, source, or examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Get) and the target (source name/UUID of a scene item). It distinguishes from sibling tools by focusing specifically on the source reference of a scene item, which no other sibling tool explicitly covers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, or any prerequisites or conditions. The description is a single sentence without contextual usage clues.
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 full burden for behavioral disclosure. It only states what the tool returns, not any side effects, permissions, or potential security implications (e.g., returning sensitive stream keys). The tool is a read operation, but this is implicit, not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that conveys the essential information. It is front-loaded with the action ('Current') and resource. The 'etc' is slightly vague but acceptable given the brevity. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple no-parameter getter, so a short description is reasonable. However, it does not specify the exact return structure or mention that settings vary by service type, which could be useful for an agent to know. It is minimally sufficient but lacks detail that would make it complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 baseline for no parameters is 4. The description adds context by listing examples of settings ('server/key'), which helps the agent understand what the response will contain without there being any input parameters to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Current stream destination service type and settings (server/key etc)' clearly indicates this tool retrieves the current stream service configuration. The word 'Current' implies a getter operation, and it specifies the resource (stream destination service type and settings). It distinguishes from the sibling set_stream_service_settings by being the getter variant, though not explicitly stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. It does not mention that this is the read counterpart to set_stream_service_settings, nor any conditions for use. The description is purely informational and provides no usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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, but it only states the action. It doesn't mention whether the filter must exist, side effects, or error conditions, leaving the agent without important 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler. It efficiently states the core action, earning its place without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but the description is minimal and lacks any behavioral or contextual detail beyond the basic action. With no output schema and no annotations, the agent has insufficient information about prerequisites or failure modes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does 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 at all. Although parameter names (source_name, filter_name) are self-descriptive, the description adds no supplemental meaning, failing to compensate 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Remove a filter from a source' uses a specific verb and resource, clearly distinguishing this tool from sibling filter operations like create_source_filter or set_source_filter_settings. It directly states the action and object.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. The description does not mention related filter operations or any prerequisites, leaving the agent to infer usage solely from the tool 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?
No annotations provided. Description only says 'Set' without disclosing whether settings are replaced entirely, whether the output must be stopped, or what side effects occur. Insufficient transparency 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no wasted words, front-loaded verb and object. Efficient and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given 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 parameter descriptions, the description is far too sparse. It omits return value, settings structure, and behavioral constraints, making it incomplete for free-form object parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has no descriptions, and the description merely adds 'named' and 'settings object', which adds minimal meaning. It fails to explain expected structure of the settings object or how output_name maps to actual outputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Uses specific verb 'Set' and resource 'a named output's settings object', clearly distinguishing from get_output_settings and other output control tools. Unambiguous action and target.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus get_output_settings, start_output, or other output-related operations. No mention of prerequisites 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?
With no annotations, the description carries full responsibility for behavioral disclosure. 'Stop' implies a state change, but it does not specify what happens if the output is not running, whether the operation is idempotent, or what errors might occur. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It is appropriately concise for a simple one-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple mutation, but the description is too sparse. It does not mention return values, error conditions, whether the output must exist or be running, or how to discover output names. Given the absence of annotations and an output schema, the description should provide more context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description only says 'named output' to clarify that the output_name parameter is the identifier. This adds minimal value beyond the property name itself and does not explain where valid names come from or any format expectations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Stop a named output' uses a specific verb (stop) and resource (output), clearly distinguishing it from sibling tools like toggle_output, start_output, and get_output_status. It effectively communicates the core action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 that start_output or toggle_output might be more appropriate for different actions, nor does it reference where to find output names (e.g., get_output_list).
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?
There are no annotations, so the description is the only disclosure. It simply says 'toggle' without revealing whether it errors on non-existent outputs, if it is idempotent, or what the return value is. This is insufficient for a mutation tool and adds little 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. It is concise and gets to the point, earning its place without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description is too thin. It omits usage context (e.g., when to toggle vs start/stop), valid output names, and potential side effects, making it incomplete for reliable selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description mentions 'named output' but does not explain that output_name corresponds to names from get_output_list or any constraints. It adds marginal meaning beyond the schema's property title, failing to compensate for the lack of schema detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'toggle' and the resource 'output', clearly stating the action. It distinguishes from siblings like start_output and stop_output by implying a state flip, and from specific toggles (e.g., toggle_virtual_cam) by being generic over named outputs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to choose this over start_output/stop_output or other toggles. The description lacks any context about selecting an output name or checking current state first, so an agent gets no help in deciding between alternatives.
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 explaining behavioral implications. Simply saying 'toggle' does not disclose whether the operation is asynchronous, what happens if the stream is already in the target state, or whether it returns the new state. The description essentially restates the function name without adding behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence that conveys the core action without waste. It is front-loaded and easy to parse. It loses one point because its brevity is partly a result of under-specification rather than intentional conciseness of rich content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple toggle tool with no parameters and no output schema, the description is minimally adequate. However, it lacks any context about the effect on overall stream state, whether there is a return value, or how it interacts with get_stream_status. Given the simplicity of the tool, a score of 3 reflects that it is acceptable but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 correctly omits parameter details since the schema is empty, and there is nothing to clarify. No additional parameter semantics are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Toggle the stream on/off' clearly states a specific verb (toggle) and resource (stream), making the tool's purpose immediately understandable. It distinguishes itself from start_stream and stop_stream by implying an action that changes the current state. However, the term 'stream' is slightly ambiguous without additional context, so it doesn't earn a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 like start_stream, stop_stream, or get_stream_status. The description provides no context about typical use cases, prerequisites, or how to decide between toggling and explicitly setting the state. This is a clear gap for a tool with many 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, the description carries the full burden of behavioral disclosure. It states a status check but does not specify the return format (e.g., boolean, value object), potential errors, or whether the operation is read-only. This is minimal and leaves important details implicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise phrase that directly states the tool's purpose. It contains no filler or redundant information, making it optimally brief for a tool with no parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple status getter with no output schema, the description should explicitly clarify the return value (e.g., 'returns true if active, false otherwise'). 'Whether' implies a boolean but does not fully specify the response structure. While adequate for a basic tool, it leaves some ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline for parameter semantics is 4. The description correctly implies no inputs are needed, and the empty schema confirms this. No additional parameter explanation is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Whether the replay buffer is active' clearly indicates this tool checks the active state of the replay buffer. It distinguishes itself from related sibling tools like start/stop/toggle_replay_buffer by focusing on status rather than manipulation, though it lacks an explicit verb.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. The description does not mention any prerequisites, exclusions, or contrast with sibling tools that perform replay buffer actions.
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 transparency. It offers only the output statement and does not explicitly disclose that this is a read-only operation, nor does it mention any potential side effects, error conditions, or prerequisites. For a simple getter, the risk is low, but the description still lacks explicit behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, succinct phrase that directly states what the tool reports. It is front-loaded, contains no filler, and every word earns its place. Perfect conciseness for a zero-parameter status getter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description is adequate but minimal. It indicates the output concept ('whether active') but does not explicitly specify the return type (boolean) or field names. In the absence of an output schema, slightly more detail could have made it fully self-contained. However, for a straightforward status check, the coverage is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the input schema already covers everything. The description does not need to explain parameters, and the baseline of 4 is appropriate. No additional semantic value is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Whether the virtual camera output is active' clearly conveys that this tool reports the virtual camera status. It uniquely targets the virtual camera resource, distinguishing it from sibling status tools like get_stream_status and get_record_status. It could be stronger with an explicit verb, but the purpose is 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/5Does 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. It does not mention that this should be used to check status before/after start/stop_virtual_cam, nor does it contrast with other status getters. Lack of any context or exclusion means no guidance is offered.
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 states the operation without disclosing side effects, prerequisites, or whether the change is reversible. For a mutation tool, 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise and front-loaded with the primary action. The Args list adds necessary parameter detail without any wasted words or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple rename tool, the description covers the purpose and parameters, but lacks context about behavior when the input is not found or how this interacts with other input attributes. Minimal but adequate for a straightforward operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The Args section explains both parameters ('Current name' and 'New name'), which compensates for the 0% schema description coverage and 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.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Rename an input') with a specific resource type, distinguishing it from sibling tools that rename scenes or filters. It is concise 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/5Does 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 set_input_settings or set_scene_name. There is no stated 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?
There are no annotations, so the description must bear the full burden of behavioral disclosure. It only says 'Rename' which implies a mutation but does not explain what happens if the scene_name is not found, whether renaming affects references to the scene, or any error conditions. This is a significant gap for a mutating operation with no structured metadata.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with one purpose sentence and two Arg lines. It avoids unnecessary fluff and is easy to parse. The only minor issue is that the Arg lines repeat information already visible in the input schema, but they do add a slight semantic value, so the structure is acceptable for its brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple rename tool, the description is minimally acceptable but not complete. It lacks discussion of failure modes, permissions, or uniqueness. Since there is no output schema, the description could at least mention that the operation either succeeds or throws an error. Given the simplicity of the operation, this is a moderate gap rather than a severe one.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 adds semantic meaning by labeling scene_name as 'Current name of the scene' and new_scene_name as 'New name,' which clarifies the role of each parameter beyond the schema property titles. However, it could provide more detail such as uniqueness constraints or case sensitivity, so it only partially compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Rename a scene' with a specific verb and resource. It is distinguishable from sibling tools like set_input_name or set_source_filter_name by explicitly targeting scenes. Even without a title, the one-line description fully conveys 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/5Does 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 prerequisites (e.g., the scene must exist) or relationships with other scene operations like create_scene, remove_scene, or set_current_program_scene. The description is only a bare statement of intent, leaving the agent without context for selecting this tool among many scene-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, the description carries the full burden of behavioral disclosure. It does not mention preconditions (e.g., whether the replay buffer must be configured), side effects, or the outcome if already running. This is a minimal statement with no behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence that is immediately clear and contains no filler. It is appropriately concise for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool without an output schema, the description is arguably sufficient, but it omits any context about the replay buffer's status or interactions with sibling tools. A brief mention of when to use start over toggle would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, and the schema is empty, so there is nothing to document. The description correctly adds no parameter information, meeting the baseline for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Start the replay buffer' uses a specific verb and resource, making the action clear. However, it does not explicitly differentiate from sibling tools like toggle_replay_buffer or stop_replay_buffer, though the verb 'start' implies the distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 toggle_replay_buffer or save_replay_buffer. The description merely states the action without context or exclusions.
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 available, the description must disclose behavioral traits itself, but it only states the action without mentioning side effects, prerequisites, or error conditions (e.g., whether starting an already-running virtual camera fails). This leaves the agent without essential behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the core action with no filler words. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no parameters, the description does not clarify what happens after starting the virtual camera, such as how success is communicated or whether it is safe to start when already active. Given the absence of annotations and output schema, this is under-specified for complete context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema already reflects this with an empty properties object. Per the rubric, a description for a tool with 0 params receives a baseline of 4, and there is no parameter information to add.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action ('Start') and the resource ('the virtual camera'), making it unambiguous. It distinguishes from sibling tools like stop_virtual_cam and toggle_virtual_cam by explicitly naming the start 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/5Does 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 such as toggle_virtual_cam or stop_virtual_cam. There are no preconditions, use cases, or contextual hints to help an agent select it appropriately.
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 behavior. It only states the action without covering side effects, error cases (e.g., switching to a non-existent profile), or reversibility. The phrase 'switch to' implies a state change but offers no further 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that communicates the essential information without any redundancy. It is well-structured and front-loaded with the action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description covers the basic purpose and parameter meaning. However, it lacks contextual details such as error behavior or the need to call get_profile_list first, which might be important for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds some meaning beyond the schema by clarifying that the 'name' parameter is the profile's name ('by name'). However, with 0% schema coverage and only one parameter, this is minimal; it could be more explicit about the parameter's role or expected format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Switch' and the resource 'profile', and specifies the mechanism 'by name'. This distinguishes it from sibling tools like get_profile_list (retrieval) and create_profile (creation), making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 vs alternatives. It does not mention prerequisites (e.g., that the profile must exist) or contrast with other profile-related actions. The usage is only implicitly derived from the stated action.
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 only states the action without mentioning prerequisites (e.g., stream must be active), potential side effects, or what happens if the stream is already stopped. 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. While extremely brief, it is appropriate for a zero-parameter tool, though it edges toward under-specification rather than effective conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool's simplicity, the description lacks essential context such as the relationship to start_stream and toggle_stream, whether it is safe to call when not streaming, and what the expected outcome/return value is. The presence of siblings makes this contextual gap significant.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema is empty (100% schema description coverage). Per rubric, a baseline of 4 applies when there are 0 params. The description does not need to add parameter details since there are none.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'End the stream.' uses a specific verb ('End') and resource ('the stream'), clearly distinguishing it from siblings like start_stream and toggle_stream. It is unambiguous and immediately understandable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. Given the sibling tools include toggle_stream and start_stream, the description does not clarify the specific circumstances (e.g., only when a stream is active) or why one would use stop_stream instead of toggle_stream.
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 that the tool creates a new, empty scene but gives no details about naming conflicts, side effects, permissions, or failure modes. This is minimal behavioral information, though 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence followed by a concise Args block. It contains no unnecessary words and is well-structured for the simple nature of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no annotations, no output schema), the description is minimal but lacks important context such as uniqueness requirements for scene names, what 'empty' specifically means in OBS, and whether the operation can fail or overwrite. It does not provide enough surrounding context for an agent to anticipate edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only provides a title 'Scene Name' with no description field (0% coverage). The description adds 'Name for the new scene,' which clearly explains the purpose of the scene_name parameter and compensates for the missing schema description. For a simple string parameter, this is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a new, empty scene' with a specific verb and resource. It distinguishes itself from related tools like create_scene_collection (which creates a collection of scenes) and create_input (which creates an input).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. It does not mention scenarios where creating a scene is appropriate, nor does it reference related operations like renaming or removing scenes. The usage is only implied by the action itself.
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. It adds the useful detail that there are exactly 6 audio mixer tracks, but it does not disclose the return format, potential errors, or behavior in edge cases. For a simple read operation, this is minimally acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that clearly communicates the tool's function without any filler or redundancy. Every word contributes to understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter getter with no output schema, the description conveys the primary purpose but omits details about the return value (e.g., whether it returns booleans, track numbers, or a list). This leaves some ambiguity about what the agent will receive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no description for the input_name parameter (0% coverage), and the description does not explain it beyond referencing 'this input'. While the parameter name is self-explanatory, the description adds no additional context about expected values or format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the intended operation: retrieving which of the 6 audio mixer tracks a given input is routed to. It uses a specific verb ('get'), identifies the resource ('audio mixer tracks'), and includes scope ('6'), distinguishing it from sibling tools like get_input_volume or get_input_balance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 or exclusions. The description simply states the functionality without context on when it would be appropriate, such as comparing to set_input_audio_tracks or other audio-related getters.
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 simply restates what the tool returns without mentioning that this is a read-only operation, how errors are handled (e.g., if the filter does not exist), or any side effects. This is a minimal description that adds little beyond the purpose 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that directly states the tool's purpose and the key returned fields. It is front-loaded and contains no filler or redundant information, 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/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple with two parameters and no output schema. The description lists the returned properties (enabled state, chain index, kind, settings), which is helpful. However, it does not describe the structure of the settings object, error conditions, or how the filter is uniquely identified beyond the two parameters. Given the lack of an output schema, slightly more detail would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage (only parameter names), and the description does not explain the roles of source_name and filter_name or how they relate. Although the names are somewhat self-explanatory, there is no guidance on expected formats, allowed values, or the relationship to sources and filters. The description fails to compensate for the schema's lack of detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the resource ('a filter's') along with the specific attributes returned (enabled state, chain index, kind, settings). This distinguishes it from sibling getter tools like get_source_filter_list or get_source_filter_kind_list, which focus on collections rather than a single filter's details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied: the description indicates this retrieves specific details of a single filter, so it is presumably used when you need those properties rather than a list of filters. However, there is no explicit guidance on when to prefer this over alternatives like get_source_filter_default_settings or when a filter might not exist, leaving the agent to infer the appropriate 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action ('Delete a scene') without revealing irreversibility, side effects on scene items, or any required permissions. This is a significant gap for a destructive 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately minimal for a tool with one parameter. It uses a clear structure: a one-line summary followed by an Args section. No unnecessary words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is incomplete for a destructive operation. It lacks warnings about permanence, impact on scene items, or any usage context. While the parameter is documented, the absence of behavioral notes makes it under-specified for safe and correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to the parameter beyond the schema, which only provides type and title. It specifies that scene_name is the 'Name of the scene to remove', clarifying its purpose. Since schema coverage is 0%, this description compensates adequately for the single parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool deletes a scene, using a specific verb ('Delete') and resource ('a scene'). It distinguishes from siblings like remove_scene_item, which removes a scene item, ensuring the agent understands the target is the scene itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, nor any context about prerequisites or consequences. The description does not mention that deletion is permanent or that associated scene items may be affected, leaving the agent without decision-making support.
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 does explain the core behavior: sets a transition to be active for the next scene switch. However, it omits potential error conditions (e.g., nonexistent transition name), whether the current transition is immediately affected, or any side effects. It is not misleading, but not rich either.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: one sentence describing the action followed by a single-argument itemization. It front-loads the main purpose and avoids fluff. The Args section is slightly redundant given the schema but is minimal and acceptable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given 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 basic action. However, it lacks context about how a transition becomes active, what happens if the name is invalid, or that related tools exist (e.g., get_scene_transition_list for lookup). For a setter tool with no annotations, this leaves small gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 provides a basic explanation for the parameter: "transition_name: Name of the transition to activate." This clarifies that the parameter expects a name rather than an ID, but it largely restates the parameter name and lacks additional context like how to retrieve valid names (e.g., via get_scene_transition_list).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action: "Make a transition the active one for the next scene switch." This clearly identifies the verb (make/set), the resource (transition), and the effect (active for next switch). It distinguishes from sibling tools like set_current_scene_transition_duration and get_current_scene_transition, which deal with duration and retrieval respectively.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. It does not mention checking available transitions via get_scene_transition_list, nor does it state prerequisites such as the transition needing to exist or the context of a scene switch. No exclusions or explicit usage context 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 merge (overlay=True) vs replace (overlay=False) behavior, which is valuable. However, it does not explain side effects on existing settings, error conditions, or any prerequisites, which limits full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one summary sentence plus two short parameter definitions. It is well-structured, immediately indicates the tool's purpose, and contains no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with two parameters and no output schema, the description is mostly adequate. Yet it does not connect to sibling tools (e.g., get_current_scene_transition) or clarify what 'current transition' means in the broader workflow, so an agent may lack the full context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no descriptions for parameters (0% coverage), so the description must compensate. It clearly explains both parameters: 'settings' is the Settings object for the transition, and 'overlay' specifies whether to merge or replace. This is sufficient for basic invocation, though the settings object structure is left open-ended.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool configures the current transition settings, with a specific example (Stinger's video file path). This distinguishes it from siblings that configure transition duration or select the transition itself, though it does not explicitly name those alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided about when to use this tool versus alternatives like set_current_scene_transition or set_current_scene_transition_duration. The usage is only implied by the description and the parameter semantics, leaving the agent to infer 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, the description carries the full burden. It discloses a prerequisite (settings must be configured) but does not explain what happens if the prerequisite is unmet, failure modes, or side effects of starting a stream. Minimal behavioral disclosure beyond the prerequisite.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, containing only two sentences with no wasted words. It front-loads the core action ('Go live') and adds one essential prerequisite, 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/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema tool, the description covers the essential purpose and a key prerequisite. However, it does not mention what a successful start returns or what errors might occur (e.g., already streaming, not configured), which could be valuable for an agent deciding whether to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is trivially complete. Per the baseline for 0 params, the description does not need to add parameter details. It does mention the required configuration, which indirectly relates to encoding/stream settings but no parameter semantics are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Go live' clearly indicates starting the stream output, with an explicit prerequisite. It distinguishes from siblings like stop_stream and toggle_stream by emphasizing the start action, though 'Go live' is somewhat informal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear context for use: requires stream service settings to be configured first, and references the appropriate configuration tool. However, it does not explicitly state when not to use this tool or mention alternatives like toggle_stream.
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 merely states 'toggle' without disclosing side effects, prerequisites, error conditions, or whether the operation is reversible. This is a mutation tool with no behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that directly states the function. For a zero-argument tool, this is appropriately sized and front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite low complexity, the description is incomplete due to missing usage guidelines and no reference to related tools like get_virtual_cam_status or start/stop. Without annotations or an output schema, the agent lacks context for correct invocation and verification.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there are no semantics to explain. The schema coverage is trivially 100% and the description adds no parameter details, which is acceptable given the absence of arguments.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: toggling the virtual camera on/off. This distinguishes it from the start_virtual_cam and stop_virtual_cam siblings by indicating a state-reversing 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this toggle versus the start_virtual_cam or stop_virtual_cam alternatives. The description does not specify contexts, exclusions, or mention checking current state with get_virtual_cam_status.
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 discloses that the event is broadcast to all subscribed clients, which is a clear behavioral trait. However, it does not mention any side effects, error conditions, or that the payload is constrained to an object, and with no annotations the description carries full burden. It is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences and front-loads the core purpose. The Args section is minimal and to the point. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter broadcast tool, the description plus schema are nearly sufficient. However, since there is no output schema, the description does not explain what the client can expect as a response or if any errors might occur. It covers the core behavior but leaves some gaps for a complete invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to 'event_data' by calling it an 'arbitrary JSON payload delivered to receivers,' which goes beyond the schema's bare type definition. However, the word 'arbitrary' is slightly misleading because the schema requires an object, not any JSON value. It provides partial clarification but not complete precision.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Broadcast a CustomEvent') and the target ('all subscribed obs-websocket clients'). This is a specific verb+resource that distinguishes it from the many siblings dealing with inputs, scenes, or transitions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, nor any exclusions or prerequisites. The description only states what it does, leaving the agent to infer its place among the large sibling list.
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 disclosure. It indicates a read-only getter for the current directory but does not mention return type, path format, or error behavior, offering minimal context beyond the 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, appropriately sized for a getter, front-loads the key information, and contains no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter getter, the description is mostly sufficient, but with no output schema or annotations, specifying the return type (e.g., a string path) would improve completeness. Despite that, the meaning is likely inferable from the name.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 adds semantic value by specifying what is being retrieved, though there are no parameter details to elaborate on.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource (output directory for recordings) and distinguishes from sibling set_record_directory, but it uses a noun phrase rather than an explicit verb, relying on the 'get_' prefix for action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives, and the sibling set_record_directory is not mentioned. Usage is only implied by the tool name.
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 some behavior, such as 'Matches to skip. -1 = last (topmost) match,' and the read-only nature implied by 'Find.' However, it does not cover error cases (e.g., no match found) or the exact return format, leaving gaps for a tool with no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured, with a clear 'Args' section that adds value without repeating schema trivia. Every sentence earns its place, and the tool's purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
As a simple lookup tool with no annotations and no output schema, the description is adequate but not complete. It covers the main parameters and purpose, but omits explicit return type, error behavior, and handling of multiple matches beyond search_offset. It is positioned somewhere between minimal and thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 provides short descriptions for all three parameters, adding meaning beyond raw names. However, the descriptions are minimal and somewhat ambiguous (e.g., 'Matches to skip' for search_offset), leaving room for clearer semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Find a scene item's numeric ID by the source name it references.' This specifies the verb (find), the resource (scene item's numeric ID), and the key distinguishing detail (by source name). It is distinct from sibling tools like get_scene_item_list or get_scene_item_source.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives. While the parameter descriptions offer some context (e.g., search_offset for skipping matches), it does not mention alternatives, exclusions, or typical use cases. The agent must infer usage.
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 explains the return value's semantics (0 = bottom), implying a read-only operation, but does not state potential errors, return type, or side-effect-free nature explicitly. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no wasted words. It front-loads the action and includes the crucial positioning detail efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no output schema, the description explains the return value (stacking position with 0=bottom), which is the key information needed. It does not need to describe return format or errors, though a note on integer type or not-found behavior would make it complete. Siblings are not relevant here.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does 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. However, the description does not mention scene_name or scene_item_id at all, relying entirely on the schema titles. It adds no extra meaning beyond what the property names already convey.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Get') and resource ('a scene item's stacking position'), with an important clarification (0 = bottom). It is easily distinguished from sibling tools like get_scene_item_list, get_scene_item_id, and set_scene_item_index.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. It does not mention any exclusions, prerequisites, or specific use cases beyond the basic action.
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 says 'Pause the active recording,' which restates the tool's name and provides minimal context that a recording must be active. It does not disclose behavior when no recording is active or when already paused, nor any error conditions or 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that earns its place. No filler words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-annotation tool, the description covers the core action but lacks important contextual details such as behavior when no recording is active or when already paused, and its relationship to toggle_record_pause and resume_record. Given the simplicity, it's adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0 parameters and 100% schema coverage, the description does not need to explain any parameters and doesn't. Baseline 4 is appropriate since 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'pause' and resource 'active recording', clearly distinguishing it from siblings like start_record, stop_record, resume_record, and toggle_record_pause. It is concise 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use pause_record versus toggle_record_pause or resume_record, nor any exclusions or prerequisites. The active recording condition is implied but not explicitly stated as a usage rule.
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 lists allowed values for monitor_type, but does not explain what the monitoring mode actually changes, any side effects, or error conditions. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using a single clear sentence followed by a compact argument list. No wasted words or redundant information; it is well-structured with each parameter on its own line.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with two parameters and no output schema, the description is mostly adequate but missing usage context and behavioral details. It does not mention when to use it, what the monitoring mode affects, or that a getter exists. This is a minimal viable description, not a complete one.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description provides meaning for both parameters: 'input_name' is clarified as a name, and 'monitor_type' has the three allowed enum values explicitly listed. This significantly enhances the bare schema information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set an input's monitoring mode') with a specific verb and resource. It distinguishes from the sibling getter 'get_input_audio_monitor_type' and other audio-set tools by naming the exact 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. It does not mention the corresponding getter or any conditions that should trigger its use, leaving the agent to infer based solely on the name.
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 discloses the overlay parameter's semantics (merge vs reset to defaults), which is valuable behavioral context not present in the schema. However, with no annotations, it does not disclose other behavioral traits such as whether the operation is destructive, requires permissions, or errors when the filter doesn't exist. The overlay explanation partially compensates but is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: a one-sentence purpose followed by a clear args list. Every line adds value and there is no redundant text. Front-loaded with the main purpose, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter tool with a nested object, no output schema, and no annotations, the description covers the core behavior and overlay semantics, but lacks contextual details such as prerequisites (source/filter existence), expected structure of filter_settings, or what happens on failure. It is a minimum viable description but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description lists all four parameters and adds meaning for overlay (merge vs reset) but provides minimal explanation for filter_settings ('Settings object') and none for source_name/filter_name beyond names. With 0% schema coverage, more detail is needed, especially for the arbitrary filter_settings object. The overlay explanation lifts it from a lower score but it remains insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does 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 ('Configure') and resource ('a filter's parameters'). It distinguishes from sibling tools like get_source_filter or set_source_filter_name by focusing on parameter configuration. Though it omits 'source' before 'filter', the tool name and sibling context make this 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives. It does not mention prerequisites (e.g., filter must exist) or contrast with get_source_filter_settings or set_input_settings. The args list implies usage but doesn't state when to choose this tool. This is a clear gap.
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 disclosure. It states only the stop action and omits side effects like whether the buffer is saved or discarded, and whether the tool has any effect if the buffer is not running.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It conveys the essential purpose in the fewest possible words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool, the description is adequate but incomplete. It lacks usage context (e.g., when to stop versus toggle) and any mention of what happens to the recorded buffer, which is relevant given the existence of save_replay_buffer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema fully covers the input structure. The description adds no parameter info, but none is needed, matching the baseline for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Stop') and resource ('replay buffer'), clearly distinguishing it from sibling tools like start_replay_buffer and toggle_replay_buffer. It is unambiguous and self-contained.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 toggle_replay_buffer or save_replay_buffer. It does not mention prerequisites, scenarios, 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 of behavioral disclosure. It mentions 'active recording' as a prerequisite but does not state what happens if no recording is active, whether the toggle is idempotent, or any side effects. The description is too minimal to adequately explain the state-changing 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, efficient and front-loaded with the action verb. Every word earns its place, with no redundant or extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (no params, no output schema), but the description still lacks context about the relationship with pause_record/resume_record and the implications of 'active recording'. For a state-mutating tool with no annotations, this is a minimal viable description but leaves gaps for an agent to infer behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema has no properties. Per the baseline for 0 parameters, the description does not need to add parameter meaning. The description adds no parameter information, but this is acceptable since there are none to explain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Toggle pause on the active recording' uses a specific verb ('toggle') and a resource ('pause on the active recording'). It clearly distinguishes itself from sibling tools like pause_record and resume_record by indicating it flips the pause state rather than setting it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 pause_record, resume_record, or toggle_record. The description does not mention any prerequisites, exclusions, or preferred contexts, leaving 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?
With no annotations, the description carries the entire burden of behavioral disclosure, but it merely restates the tool name. It does not explain side effects, state dependencies, or any potential failures (e.g., what happens if the buffer is already on/off).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of six words, front-loaded with the action verb and resource, containing no filler or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimally viable for a simple toggle with no parameters, but it lacks any mention of behavioral nuances such as state dependence or relationship to the sibling start/stop commands. Given the availability of more specific alternatives, the completeness is adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is fully covered, so the baseline is 4. The description adds nothing about parameters, but none are needed; the schema already reflects this.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'toggle' and the resource 'replay buffer', with an explicit on/off scope. This distinguishes it from sibling tools like start_replay_buffer and stop_replay_buffer, which describe more specific actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 instead of the more specific start_replay_buffer or stop_replay_buffer siblings. It lacks any context about prerequisites or scenarios, leaving the agent without direction on choosing the appropriate tool.
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 mentions the side effect of adding the input as a scene item, but does not disclose prerequisites (e.g., scene must exist), error behavior, permission requirements, or what happens if input_kind is invalid or scene_name is empty. 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loaded with the primary purpose, and the Args section is organized and scannable. Each line adds some value, though it partially duplicates schema property names. It is appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description covers the core action and parameter semantics but omits the return value, error conditions, and prerequisites. It is adequate for a straightforward create tool but lacks completeness for scenarios like missing scenes or invalid kinds.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description compensates with meaningful explanations: input_kind references get_input_kind_list for valid values, input_settings is labeled as optional, and scene_item_enabled is clarified as 'starts visible'. It adds context beyond the bare property names, though it does not address what an empty scene_name means.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Create') with a clear resource ('input') and outcome ('add it as a scene item to a scene'). It distinguishes this tool from siblings like remove_input, set_input_name, and create_scene_item by combining creation of the input with adding it to a scene.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: use when you need to create an input and add it to a scene. However, it does not explicitly state when not to use it or mention alternatives such as create_scene_item (which might add an existing source to a scene). No exclusions or alternative tool references are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavioral traits. It adds useful context by noting the unit (milliseconds) and that the value can be negative, implying it may return signed numbers. However, it does not explicitly confirm read-only behavior or explain error scenarios, which is a gap for a tool with no annotation safety hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the primary action and includes a key behavioral detail (unit and sign). No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with one parameter and no output schema, the description covers the essential purpose and return unit. It could be more complete by explicitly stating that the return is a numeric value, but the phrase 'offset in milliseconds' implicitly conveys this. Overall, sufficient for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero description coverage for the only parameter 'input_name'. The description partially compensates by indicating the parameter refers to an input whose offset is being retrieved, but it does not elaborate on the expected format or source of the name. This provides baseline meaning beyond the schema's bare string type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does 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: 'Get an input's audio sync offset in milliseconds'. It distinguishes itself from siblings like 'set_input_audio_sync_offset' and other getters by focusing on the audio sync offset specifically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not mention when to use this tool versus alternatives, nor any prerequisites or exclusions. It simply states what it does, leaving the agent 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.
- 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 usefully discloses that the list reflects what the current OBS install can create (dynamic), but it does not explicitly confirm read-only behavior or absence of side effects, though 'List' implies this.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently states the verb, resource, and scope without any unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple enumeration tool with one optional boolean parameter, the description covers the core purpose but ignores the parameter entirely and does not describe the return structure (no output schema exists). Given the undocumented parameter, completeness is only average.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage and the description does not mention the 'unversioned' parameter at all. The agent has no semantic understanding of what toggling 'unversioned' does, and the description 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/5Does the description clearly state what the tool does and how it differs from similar tools?
Description uses the specific verb 'List', identifies the resource as 'input kind (source type)', and scopes it to 'this OBS install can create'. This clearly distinguishes it from sibling tools like get_input_list (which lists existing inputs) and get_source_filter_kind_list (which lists filter kinds).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance is provided, nor any mention of alternative tools. The intended use scenario is implied by the description but not stated as a guideline.
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 burden. It discloses that the tool retrieves an override 'if any,' implying a possible null/absent result, but it does not describe the return structure or any side effects. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise and front-loaded, with the primary purpose in the first sentence and a minimal Args section. Every sentence serves a functional purpose, though the Args line duplicates schema information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter getter, the description is mostly sufficient, but it does not define what a 'transition override' is or describe the return value's structure or type. Given no output schema, the description should clarify what the caller receives, especially the 'if any' case.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must add meaning beyond the schema. It merely restates 'scene_name: Name of the scene,' which adds little beyond the schema's existing title 'Scene Name.' No format, constraints, or clarifications are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Get') and the resource ('transition overridden for a specific scene'), making it distinguishable from related tools like get_current_scene_transition. The phrase 'if any' adds nuance about the optional nature of the override.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does 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 need to know the transition override for a particular scene. However, it does not explicitly mention alternatives or exclusions, such as when to use get_current_scene_transition instead, leaving usage guidance implicit.
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 burden. It fails to disclose whether the operation replaces or merges existing track assignments, and does not mention errors, idempotency, or effects on unspecified tracks. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the purpose, and uses a clear Args structure. Every element earns its place with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite good parameter documentation, this is a mutation with no annotations and no output schema. The ambiguous effect on unspecified tracks (replace vs. merge) creates a significant completeness gap for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds substantive meaning beyond the schema: it specifies input_name as 'Name of the input' and audio_tracks with a concrete example and track range (1-6). This compensates well for the 0% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set') and the resource ('audio mixer tracks an input is routed to'), making it distinct from sibling tools like get_input_audio_tracks. 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 Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the setter nature, but there is no explicit guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. The context suggests it is for configuring audio routing, but no alternatives are named.
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 carry the full behavioral disclosure burden. It only states the action without detailing error behavior, prerequisites, idempotency, or side effects. For a mutation tool, this lack of transparency 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and uses a clear Args structure. Every sentence adds value, though the blend_mode enumeration could be slightly more explicit with the full 'OBS_BLEND_' prefix on each option. No unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given 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, the description covers the essential parameters but omits contextual details such as return behavior, error conditions, or whether the scene item must already exist. It is adequate for basic use but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides zero parameter descriptions (0% coverage), so the description's Args section compensates well by explaining each parameter. Notably, it enumerates the allowed blend_mode values, adding meaning beyond the bare schema titles and types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Set a scene item's blend mode' which uses a specific verb and resource, clearly distinguishing it from the sibling get_scene_item_blend_mode. It leaves no ambiguity about 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by the verb 'Set' but provides no explicit guidance on when to use it vs alternatives, prerequisites, or exclusions. It does not mention that reading the blend mode is available via a sibling tool, leaving usage context to inference.
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 behavioral disclosure burden. It only says 'set' which implies a mutation, but it does not disclose side effects, whether the transform is fully replaced or partially merged, error conditions, or any prerequisites like the item needing to exist in the scene. This is a gap for a setter 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: a single clear sentence followed by a structured Args list. It is front-loaded with the main purpose. The Args section is somewhat redundant with the input schema but is formatted in a readable way. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a nested transform object and three required parameters, and no output schema. The description enumerates the transform fields but does not explain units (e.g., rotation degrees), whether partial transforms are allowed, or what happens when invalid values are provided. It is adequate but leaves several gaps for safe usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. The Args block adds meaning to scene_name and scene_item_id, and critically enumerates the valid keys inside the 'transform' object (positionX/positionY, rotation, scaleX/scaleY, alignment, boundsType, cropLeft, etc.), which the schema leaves as an unstructured object. This provides significant value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Set') and identifies the resource ('a scene item's position/scale/rotation/crop'). It clearly distinguishes this from sibling tools like get_scene_item_transform or set_scene_item_enabled by naming the exact transform properties.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: it is for modifying a scene item's transform. However, it does not explicitly state when to use this tool versus alternatives, nor does it mention any prerequisites or when not to use it. The context is clear but lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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 explains how to set service_type and settings but does not disclose that this is a state-changing operation that may affect live streaming, require authentication, or behave differently for other service types. The only extra behavioral context is the example for a plain RTMP target.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded, with the purpose in the first line. The Args section is minimal and the example is valuable, though it partially duplicates parameter names already present in the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations or output schema, the description provides only basic guidance. It covers the rtmp_custom case but leaves rtmp_common and other service types undefined, and lacks information about validation, potential side effects, or the expected response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no property descriptions, so the description is the sole source of parameter meaning. It explains service_type with examples and defines settings as a service-specific object. The rtmp_custom example gives concrete structure for the settings parameter, adding value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Set the stream destination' with a specific verb and resource, distinguishing it from the sibling get_stream_service_settings. The example for rtmp_custom further clarifies its 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a concrete usage example for rtmp_custom, indicating when this setting is appropriate. However, it does not explicitly mention alternatives or when not to use it, relying on the reader to infer context from the example.
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. It discloses that the operation adds an item and mentions visibility via scene_item_enabled, but does not describe return values, error behavior, effects on existing items, or prerequisites beyond 'existing source'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the main verb, followed by a clear Args section. Every sentence adds value, with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple mutation tool with no annotations or output schema, the description covers all parameters and the core purpose. However, it lacks details on return values, failure modes, or positional behavior (e.g., where the new item is placed), leaving some gaps for an agent to fully understand the operation's consequences.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no descriptions, so the description compensates by explaining each parameter: scene_name ('Scene to add the item to'), source_name ('Existing source (input) to place'), and scene_item_enabled ('Whether it starts visible'). This adds meaningful semantics beyond the schema's names and types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Add an existing source to a scene as a new scene item.' This uses a specific verb ('Add') and resource ('scene item'), and distinguishes from siblings like create_scene or create_input by specifying it adds an existing source.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by requiring an 'existing source' and a scene, but does not explicitly state when to use versus alternatives like create_input or create_scene. It provides context but no exclusions or alternative references.
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 adds the studio-mode constraint but fails to disclose what happens outside studio mode (e.g., error, null return) or what the return value represents (scene name, ID, object). This leaves significant behavioral ambiguity for a getter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence that states the tool's essence and a critical caveat. It is front-loaded and contains no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple no-parameter getter, the description covers the key context (preview scene, studio mode). However, it omits any mention of the return value format, which could be important since no output schema is provided. Still, the simplicity of the tool makes this a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema shows an empty object. The description adds nothing about parameters, but with no params, the baseline is 4 and no additional info is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the specific resource (the current preview scene) and distinguishes it from the program scene by name and context. However, it lacks an explicit verb like 'returns' or 'gets', relying on the tool name to convey the action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The note 'Only meaningful in studio mode' provides clear context for when the tool is appropriate, implicitly distinguishing it from program-scene queries in non-studio modes. It doesn't explicitly name alternatives like get_current_program_scene, but the context is 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?
With no annotations, the description carries the burden of disclosing behavior. It conveys that this is a read operation and adds the useful scale context. However, it does not mention potential errors (e.g., invalid input name), return value type, or whether any state changes occur, which is a moderate gap for a getter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that front-loads the core purpose and includes essential scale information. 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/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema, no annotations), the description provides the essential range but lacks explicit details about the return value format and error behavior. It is adequate for a minimal getter, but could be more complete by stating what the function returns and any notable edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for input_name, so the description must compensate. It refers to 'an input' implying that input_name identifies the audio input, but it does not clearly define acceptable values, naming conventions, or how it relates to the tool's result. It adds some meaning beyond the bare schema but not enough to fully clarify the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the resource ('an input's stereo balance'), and specifies the value range (0.0 full left to 1.0 full right). This distinguishes it from sibling tools like set_input_audio_balance and get_input_volume, leaving no ambiguity about its function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions. Usage is implied by the getter semantics and the contrast with the setter sibling, but no explicit guidance is provided, so it falls at the 'implied usage' level.
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 shoulder the burden. It discloses the return fields and includes state information ('active/reconnecting'), but it does not mention error behavior, requirements (e.g., output must exist), or whether the output needs to be running. For a simple getter, this is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the core purpose and then lists concrete data items. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only status tool with no output schema and no annotations, the description covers the essentials: what the tool does and what fields are returned. It lacks usage context relative to sibling status tools, but the tool is simple enough that the description is nearly sufficient. The missing guidance on when to use this versus get_stream_status/get_record_status prevents a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter is 'output_name', and the schema description coverage is 0%. The description mentions 'named output' but provides no guidance on valid values or where to obtain the output name (e.g., via get_output_list). The parameter name is self-explanatory, but the description adds minimal extra semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves 'Detailed status of a named output' and enumerates specific data fields (active/reconnecting, timecode, duration, congestion, bytes sent, frame counts). This distinguishes it from sibling tools like get_stream_status or get_record_status which focus on specific output types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies it is for a named output (likely from get_output_list), but it does not explicitly state when to use this over similar status tools like get_stream_status or get_record_status. No alternatives are mentioned, and no exclusions are given.
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 indicates a read-only listing operation, but does not explicitly confirm absence of side effects, permissions, or response structure. For a simple list tool, the transparency is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action and resource. It contains no redundant information and is easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given 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), the description provides the essential information: it lists all profiles and identifies the active one. It could be more detailed about the return format, but for a zero-parameter read-only operation it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is already fully covered. The description adds nothing about parameters, which aligns with the baseline for parameter-less tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does 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 ('List') and resource ('profiles'), and adds that it identifies the currently active one. This distinguishes it from profile-mutating tools like set_current_profile, though it does not explicitly contrast with sibling list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The implied usage is straightforward: call this tool to see all profiles and the active one. However, there is no explicit guidance on when to use it versus alternatives, no exclusions, and no mention of prerequisites or 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?
With no annotations, the description carries the full burden. It conveys that the tool reads visibility state and is non-mute, which is useful. However, it does not disclose the return type (boolean implied), potential errors (e.g., invalid scene or item ID), or any side effects. It provides basic behavioral context but leaves 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the purpose and adds a clarifying parenthetical. Every word earns its place, with no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with two clear parameters and no output schema, the description is largely adequate. It specifies the visibility semantic and implicitly indicates a boolean result. However, it could be more complete by noting how to obtain scene_item_id or mentioning the return value type, but the simplicity keeps it at a high level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does 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 parameters at all. The parameter names 'scene_name' and 'scene_item_id' are somewhat self-explanatory, but no guidance is given on how to obtain valid values (e.g., that scene_item_id comes from scene item lists). The description fails to compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('scene item'), and clearly states the exact semantic ('currently visible (shown/hidden, not mute)'). This distinguishes it from sibling tools like set_scene_item_enabled and clarifies it is not about mute state, which could be confused with get_input_mute.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for checking visibility state, but it does not explicitly state when to use this versus alternatives like set_scene_item_enabled or get_input_mute. The parenthetical 'not mute' hints at an exclusion, but no explicit usage scenario or alternative names are 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. It only restates the function without disclosing read-only behavior, return format, potential errors, or ordering. The verb 'List' implies a safe read operation, but that is not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that is front-loaded with the action and resource. It contains no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and no output schema. The description covers the core purpose but lacks details about return values, behavior on missing scenes, and usage compared to sibling scene-item tools. It is minimally viable but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 scene_name parameter. However, the parameter name and title ('Scene Name') are self-explanatory, and there is only one required parameter, so the baseline is acceptable though not enriched.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List'), the resource ('every scene item'), and the scope ('in a scene'). It distinguishes from siblings like get_scene_list (lists scenes) and get_group_scene_item_list (lists group scene items).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'in a scene' gives clear context for when to use this tool, but it does not explicitly mention alternatives or exclusions (e.g., not for group scene items). No other usage 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?
With no annotations, the description must disclose behavioral traits. It only says 'press a button' without mentioning side effects, error conditions, or the nature of the operation (e.g., that it may trigger a reload). The example gives a use case but no behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, front-loaded with the main action, and includes only essential parameter definitions. Every sentence 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/5Given 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, the description covers the basic purpose and parameters. However, it lacks behavioral details such as what happens when the property is missing or what side effects the button press may have. It is adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description compensates by defining both input_name and property_name in simple terms. It adds an example for property_name, which helps clarify the expected value. This is helpful but not deeply detailed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action (press) on a specific resource (a button in an input's properties) and provides a concrete example (refreshnocache). This clearly distinguishes it from sibling tools like get_input_properties_list_property_items and open_input_properties_dialog.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through the example of refreshing a browser source, but it does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions. The guidance is minimal and inferred 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 of behavioral disclosure. It states the action but does not disclose what happens if the recording is not paused (e.g., error, no-op), whether the operation is reversible, or any side effects. For a state-changing tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no extraneous words. It is front-loaded with the core action and resource, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (no params, no output schema), and the description covers its primary purpose. However, it does not mention any prerequisites or failure behavior, and it does not clarify how it differs from toggle_record_pause, leaving some contextual ambiguity for an agent selecting between them.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the description does not need to explain parameter semantics. The baseline of 4 applies, and there is no omission.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Resume a paused recording.' uses a specific verb and resource, making it clear that this tool resumes a previously paused recording. It clearly distinguishes from sibling tools like pause_record, toggle_record_pause, start_record, and stop_record by focusing solely on the resume action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a recording is paused ('a paused recording'), but it does not explicitly state when not to use it or mention alternatives such as toggle_record_pause, which can also resume. The usage context is implied rather than fully articulated.
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 responsibility for disclosing behavioral traits. It does not mention side effects such as whether existing files are overwritten, whether directories must already exist, whether the source must be active/visible, or what the return value will be. The parameter ranges for width/height and compression quality are useful, but they do not address the tool's overall behavior and potential failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, starting with a one-sentence summary followed by a clear Args list. Each argument gets a brief, focused explanation without unnecessary detail. The format is easy to scan and does not waste words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with six parameters and no output schema, the description covers all parameters and the core action well. However, it omits information about the return value or response, and does not address error conditions or file-overwrite behavior. Given the lack of an output schema, a brief note on what to expect would improve completeness, but the existing content is largely sufficient for basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does 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 does so thoroughly: source_name is explained, image_file_path includes an example, image_format lists examples, image_width/image_height describes scale-to-fit with bounds, and image_compression_quality explains the numeric range and default. Every parameter is given meaningful semantics beyond its schema title.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Save a screenshot of a source (input or scene) directly to disk.' It uses a specific verb (Save), identifies the resource (source input/scene), and specifies the outcome (directly to disk). This distinguishes it from the sibling get_source_screenshot, which likely retrieves image data rather than saving to a file.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention get_source_screenshot or any other sibling, nor does it state exclusions or prerequisites. The only hint is the phrase 'directly to disk,' which implies a use case but does not explain when this is the right choice over other screenshot-related tools.
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 burden of behavioral disclosure. It mentions switching the live program scene and that the scene name must be exact, but does not disclose potential errors, side effects, or whether it affects transitions or studio mode.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with the action stated upfront and an Args section that covers the parameter without filler. Every sentence adds value, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description provides the essential purpose and parameter semantics. However, it lacks details on failure behavior (e.g., non-existent scene) and any side effects, which would be useful given the lack of annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero coverage (no param description), but the description compensates by explaining scene_name as 'Exact scene name (see get_scene_list).' This gives crucial guidance: exact match required and how to obtain valid values, which is sufficient for a single-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Switch the live Program scene — the core "cut to this scene" action.' This uses a specific verb and resource, and distinguishes it from siblings like set_current_preview_scene by emphasizing the live program and cut action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context that this is the 'core cut' action and refers to get_scene_list for valid names, implying when to use it. However, it does not explicitly contrast with alternatives like set_current_preview_scene or state when not to use this tool.
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. It does not mention side effects, prerequisites (e.g., input existence), error behavior for invalid field_order, reversibility, or whether the change applies immediately. The only behavioral hint is the allowed values for field_order, which is more parameter semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with a one-sentence purpose followed by a clear args list. Every element serves a purpose, and it is front-loaded with the action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given 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 gives the essential purpose and parameters, but it lacks context on error conditions, side effects, or usage conditions. It is minimally adequate but not rich.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It does: it names both parameters and provides the allowed values for field_order ('OBS_DEINTERLACE_FIELD_ORDER_TOP or _BOTTOM'). This adds meaningful clarity beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Set an input's deinterlace field order.' It uses a specific verb ('Set') and a precise resource ('input's deinterlace field order'). This distinguishes it from sibling tools like get_input_deinterlace_field_order and set_input_deinterlace_mode.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage from the purpose but does not explicitly state when to use this tool versus alternatives. There is no mention of when not to use it or reference to related getter/setter tools. The guidance is adequate for a straightforward setter but lacks explicit 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, the description carries the full burden of behavioral disclosure, but it only states the action and parameter meanings. It does not mention side effects, prerequisites (e.g., input must exist), error behavior, or whether the mode change applies immediately to the active output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise: a single actionable sentence followed by a minimal Args block. It is front-loaded, with no unnecessary words or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with two parameters, the description covers the basic invocation but omits important context such as error conditions, compatibility with input types, and whether the operation is synchronous. No output schema exists, so the description does not need to explain return values, but behavioral details are missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description compensates by listing the allowed mode values (OBS_DEINTERLACE_MODE_*), which is essential for correct invocation. Input_name is only described as 'Name of the input', which adds little beyond the schema's title, but the mode list provides significant semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set') and the specific resource ('an input') and property ('deinterlace mode'). It distinguishes itself from sibling getters like get_input_deinterlace_mode and other setters by naming the exact property being modified.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does 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 need to set an input's deinterlace mode) but does not explicitly mention alternatives or exclusion cases. No guidance is given about when to use this versus the getter or related field-order setter.
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 disclosing behavior. It explains the overlay parameter semantics (merge vs. reset), which is important behavioral context. However, it does not disclose potential side effects, error conditions, or whether the operation is reversible, leaving 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured with an Args block. Every sentence provides useful information, and there is no redundancy or irrelevant content. It is appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core purpose and parameter semantics, making it minimally usable. However, it lacks contextual completeness by not addressing potential errors (e.g., invalid input_name), return values, or when this tool is preferred over sibling setters. Given no output schema and no annotations, more context would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Since schema description coverage is 0%, the description must explain parameters. It successfully does so: input_name is 'Name of the input', input_settings is 'Settings object to apply', and overlay is clearly defined with True/False behavior. This adds meaning beyond the bare schema, though it could be more detailed about the structure of input_settings.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Set' and the resource 'an input's settings', distinguishing it from siblings like get_input_settings and more specific setters such as set_input_mute or set_input_audio_tracks. It unambiguously identifies the tool's primary 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/5Does 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. It does not mention, for example, whether to prefer this over set_input_mute for single property changes, or any prerequisites or exclusions. The description is purely functional, not contextual.
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 restates the tool's name (toggle_record) with the phrase 'on/off' without explaining the state-dependent behavior (e.g., if recording, it stops; if not, it starts). This minimal detail 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the key action. Every word is necessary, and there is no redundancy or unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with no parameters and no output schema, so a short description is acceptable. However, the description lacks explicit detail about the conditional behavior of toggling (what happens if already recording) and does not reference related tools, making it minimally complete but not fully informative for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description is not required to add parameter semantics. With an empty schema, the baseline of 4 applies, as there are no parameter details to clarify.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Toggle recording on/off.' uses a specific verb ('toggle') and resource ('recording') to clearly state the tool's function. It distinguishes itself from sibling tools like start_record, stop_record, and toggle_record_pause by indicating it flips the recording state between on and off.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a user wants to switch the recording state, but it does not explicitly state when to choose this over start_record or stop_record. No alternative tools are mentioned, leaving the decision to the agent's inference from the verb 'toggle'.
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 behavioral traits itself. It only states the action types and does not mention side effects, error behavior, or whether the tool modifies persistent state. 'Trigger' implies an effect, but the description does not detail what happens upon success/failure or whether permissions are required.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the primary verb phrase, and then a brief parameter list. Every sentence is informative and 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/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter action tool, the description covers the purpose, parameter meanings, and allowed values. However, it omits any mention of return values, prerequisites (e.g., the media source must be a media input), or typical use cases. Given the tool's simplicity, it is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description carries the full burden. It adds crucial meaning by defining 'input_name' as 'Name of the media input' and, more importantly, enumerates the valid values for 'action' (PLAY, PAUSE, STOP, RESTART, NEXT, PREVIOUS). This fills the gap left by the bare schema types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear verb+resource: 'Trigger a transport action on a media source.' It enumerates the specific allowed actions (play, pause, stop, restart, next, previous), which distinguishes it from sibling tools like get_media_input_status or set_media_input_cursor that query or seek rather than control transport.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use the tool (to control media playback via transport actions) but does not explicitly contrast it with alternatives or state when not to use it. Since the sibling list includes other media-related tools, some explicit guidance would elevate this dimension beyond a minimum viable score.
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. It discloses both creation and switching behaviors, which is useful, but it omits details about potential errors (e.g., duplicate name) or default settings of the new profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no redundant words, effectively front-loading the primary action and its side effect.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple mutation with no output schema, the description covers the core behavior but lacks details on edge cases (e.g., what happens if the profile name already exists) and does not specify return values. It is minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explicitly explain that the 'name' parameter is the name for the new profile. The semantics are only inferable from the tool name, so the description fails to compensate 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a new profile and switches to it, using a specific verb and resource. This distinguishes it from sibling tools like set_current_profile or remove_profile.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when creating and switching to a new profile, but it does not explicitly mention alternatives such as set_current_profile for switching to existing profiles or remove_profile for deletion.
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 is a simple read operation, and the description implies no side effects. However, it does not disclose error behavior, required permissions, or return format beyond listing possible values. The behavior is fairly transparent, but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the action and object. It includes essential details (the possible modes) without any waste, achieving maximum efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description covers the essential purpose and return values. It could explicitly state the return type, but listing the three modes effectively communicates what to expect. The description is complete enough given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for the single parameter 'input_name'. The description refers to 'an input' but does not elaborate on how to specify the input name (e.g., source name vs UUID). The parameter name is self-explanatory, but the description adds little semantic value beyond what the schema shows.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get an input's monitoring mode', with a specific verb and resource. It also lists the possible return values (none / monitor-only / monitor-and-output), which distinguishes it from sibling getters like get_input_mute and get_input_audio_tracks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (retrieve monitoring mode for an input) but does not explicitly state when to use this tool versus alternatives or any prerequisites. Given the straightforward nature of a getter, the context is clear enough, but there is no explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry behavioral disclosure. It usefully reveals that the returned object is a base/default layer and that get_input_settings supplies overrides. However, it doesn't describe the return format, error behavior for unknown input kinds, or any required permissions, leaving 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
One concise sentence with an em-dash that front-loads the core purpose and adds the overlay relationship. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter, but without an output schema or annotations, the description should explain the return structure more explicitly and note how to discover valid input_kind values. The overlay hint is valuable but leaves operational details unstated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description only restates the 'input kind' concept without adding details about valid values or how to enumerate them. It doesn't mention get_input_kind_list, so the parameter remains underspecified beyond its name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a default settings object for an input kind, and explicitly distinguishes it from get_input_settings by explaining the overlay relationship. This makes the tool's scope unambiguous among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear usage context by explaining that get_input_settings should be overlaid on the returned defaults to reconstruct effective settings. It doesn't explicitly mention when not to use it, but the relationship to sibling tools implies the division of responsibility.
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 a key behavioral constraint (async inputs only), but does not explain behavior on non-async inputs, return format, or error handling. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two concise sentences that state the purpose and the key usage constraint without any redundant content. It is front-loaded and highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and no output schema, so the description is mostly adequate. However, it does not mention what the response contains (e.g., mode values) or potential errors for non-async inputs, leaving some gap 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.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter (input_name) with 0% description coverage. The description provides no additional meaning for the parameter, such as accepted formats or how to identify the input, leaving the agent to rely solely on the schema's 'Input Name' label.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get an input's deinterlace mode' with a specific verb and resource, distinguishing it from the sibling set_input_deinterlace_mode and get_input_deinterlace_field_order. The additional 'Async inputs only' further scopes 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 Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states the tool is for 'Async inputs only (capture cards, etc)', giving clear context on when to use it. However, it does not mention alternatives or what to use for non-async inputs, so it falls short of full when/when-not guidance.
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 behavioral disclosure. It adds useful context by explaining what 'locked' means (can't be moved/resized in UI), but it does not disclose the return format (e.g., boolean), error behavior, or any side effects. This is a simple read operation, so the missing details are notable but not critical.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that directly states the tool's purpose and adds a brief, relevant parenthetical. Every word earns its place, and no fluff or redundant information is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple getter with two parameters and no output schema. The description explains what a lock state is, but it omits the return value shape (presumably a boolean) and any error cases like invalid scene/item IDs. Given the simple nature, this is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not compensate by explaining the parameters. While scene_name and scene_item_id are somewhat self-explanatory, the description does not clarify how to obtain the scene_item_id or how the two parameters relate. It adds no meaning beyond the schema's property names and types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('a scene item's lock state'), making the tool's function immediately clear. It also distinguishes itself from the sibling set_scene_item_locked by focusing on reading lock state, and the parenthetical clarifies the practical meaning of 'locked'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use this tool: when you need to check whether a scene item is locked. It does not explicitly mention alternatives, but the presence of set_scene_item_locked in the sibling list makes the get vs. set distinction obvious. There are no exclusions or conditional guidance, so it stops 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.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds context by defining studio mode as 'separate Preview/Program' and implies a read-only query. However, with no annotations, it does not explicitly state that the operation has no side effects or that it returns a boolean, leaving the behavioral burden partially unmet.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the essential information. It avoids redundancy and is appropriately sized for a simple getter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given 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), the description is largely complete. It explains what studio mode means and what state is being queried, though explicitly stating the return type (boolean) would make it fully self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
This tool has zero parameters and the schema is empty, so there is nothing for the description to add. The baseline of 4 applies due to the absence of parameters, and the description correctly focuses on the tool's purpose rather than parametrization.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool reports whether studio mode (separate Preview/Program) is enabled, using a specific verb and resource. It distinguishes itself from siblings like set_studio_mode_enabled and trigger_studio_mode_transition by focusing on the boolean state query.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. It does not mention set_studio_mode_enabled or other related tools, nor does it give any exclusion criteria or context about when a getter is appropriate.
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 full responsibility for behavioral disclosure. It only states the basic action without mentioning potential side effects like foreground focus, modal behavior, or error conditions if the input does not exist. This is a notable gap for a UI-interaction 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no filler. It directly communicates the tool's purpose without wasting words, earning the highest score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one param, no output schema, no annotations), the description is mostly complete. It could mention prerequisites like the input existing, but for a basic UI action, the lack of such detail is acceptable. The missing behavioral aspects are already penalized under transparency.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has a single parameter 'input_name' with no description, and the tool description also does not explicitly explain it. However, the param name is self-explanatory, and the description references 'an input,' which matches the parameter. Since schema coverage is 0%, the description offers no additional semantic value, but the simplicity of the parameter keeps it at baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Open an input's Interact dialog in the OBS UI.' It specifies the verb (open), the resource (input's Interact dialog), and the context (OBS UI). This distinctly differentiates it from sibling dialog-opening tools like open_input_properties_dialog and open_input_filters_dialog.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by naming the specific dialog type. However, it does not explicitly contrast with alternative dialog-opening tools, so an agent might not know when to choose Interact over Properties or Filters. Still, the context is clear enough for a single-purpose UI action.
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 of behavioral disclosure. It explicitly states the significant side effect 'Removes all its scene items too', which is critical for a destructive operation. However, it does not mention reversibility, permissions, or error behavior, so it is not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: 'Delete an input' immediately conveys the purpose, followed by the key side effect and a minimal Args list. Every sentence is useful and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple deletion tool with one parameter and no output schema, the description covers the essential behavior and side effect. It lacks details about error handling or prerequisites (e.g., input must exist), but these are likely unnecessary for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 defines the only parameter as 'Name of the input to remove', clarifying the semantic meaning. It does not add format constraints or edge-case details, but for a single string parameter it is adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Delete an input', which is a specific verb+resource. It further clarifies scope with 'Removes all its scene items too', distinguishing it from sibling tools like remove_scene_item or set_input_name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 create_input or remove_scene_item. No exclusions or prerequisite conditions are mentioned, leaving the agent to infer usage solely from the name.
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 full burden of behavioral disclosure. It reveals an important behavior (switching away from the active profile before removal) but does not mention that removal is permanent or irreversible, or any potential side effects or error conditions. This is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short, front-loaded sentences. The first sentence states the primary action clearly, and the second adds a critical behavioral nuance. There is no redundant or extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple destructive tool with no annotations or output schema, the description covers the core purpose and the active-profile edge case. However, it lacks details about permanence, error handling, or prerequisites (e.g., listing profiles first), making it minimally complete but not fully thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one required parameter 'name' with no description (0% coverage). The tool description does not explain the parameter beyond the obvious 'profile name', and does not clarify where to obtain valid values or any format constraints. This leaves the parameter's meaning largely implicit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool removes a profile, using the specific verb 'Remove' and identifying the resource ('a profile'). It also adds a distinguishing behavioral note about handling the active profile, which sets it apart from sibling profile management tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (to delete a profile) but does not explicitly mention alternatives or exclusions. The added note about OBS switching away from the active profile provides context on edge-case handling, which is useful for decision-making.
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 is responsible for behavioral disclosure. It adds the fact that the operation 'Blocks until the switch completes', which is useful. However, it does not mention error behavior, required permissions, or side effects beyond the switch itself, 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the primary action, and contains no extraneous words. Every part earns its place, 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.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with one parameter and no output schema or annotations, the description is mostly complete. It states the action and the blocking behavior, which is sufficient for an agent to invoke it correctly. It could mention that the name must exist, but the simplicity of the operation keeps the gap small.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. The phrase 'by name' clarifies that the 'name' parameter is the identifier of the scene collection to switch to, which adds some meaning beyond the bare schema. Still, it provides no additional detail on constraints or source of the name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Switch to a scene collection by name' clearly identifies the action (switch) and resource (scene collection), with a specific scoping parameter ('by name'). This differentiates it from siblings like get_scene_collection_list (listing) and create_scene_collection (creation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used to change the current scene collection, but does not explicitly state when to use it versus alternatives or mention prerequisites like obtaining a valid name from get_scene_collection_list. The usage is clear from context but not explicitly detailed.
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 gives the balance range but does not disclose error behavior, prerequisites (e.g., input must be audio), side effects, or whether changes are reversible. For a mutation tool, 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is minimal and well-structured: a single sentence for purpose followed by a clean parameter list. Every word earns its place; no fluff or redundant repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with low complexity, the description covers the core purpose and parameters. However, it lacks usage guidelines, error handling, and return value expectation (no output schema). It is adequate but leaves gaps 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.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description fully explains both parameters: input_name as 'Name of the input' and balance with its range 0.0 (left) to 1.0 (right) and center at 0.5. This adds meaning beyond the bare schema, which has no descriptions for these properties.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Set an input's stereo balance' clearly states the action and resource. It distinguishes this setter from sibling tools like get_input_audio_balance and other set_* audio controls (e.g., set_input_volume).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied by the verb 'Set' but there is no explicit statement of when to use this tool versus alternatives. The sibling list includes get_input_audio_balance, but the description does not mention that relationship or any prerequisites.
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, but it only states the intended effect. It does not disclose whether the directory must already exist, whether it is created, whether the change is persistent, or what happens on invalid paths. This is a minimal behavioral disclosure for a setter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one clear sentence plus an Args list. It is front-loaded with the purpose and contains no redundant wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter setter, the description covers the main purpose and parameter semantics. However, it omits any behavioral cautions (e.g., directory creation, validation), which would make it fully complete given the absence of annotations. Still, it is reasonably complete for its minimal scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage (only a title 'Path'). The description compensates by stating 'Absolute directory path' in the Args, adding clarity on the expected format. Since there is only one parameter, this fully addresses its meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Set') and resource ('output directory recordings are written to'), clearly distinguishing it from the sibling 'get_record_directory' which retrieves the directory. It leaves no ambiguity about 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 Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (setting the record directory) but provides no explicit when-to-use or exclusions. It does not mention the alternative 'get_record_directory' for reading the current value, so guidance is only implicit.
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 action and index semantics, omitting side effects on other filter positions, error behavior for invalid indices or non-existent filters, and any permission requirements. This is a mutation tool, so more transparency is expected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core action in the first sentence. The Args section is minimal, with one line per parameter, and every piece of information is useful and relevant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple mutation tool, the description covers the operation and parameters, but lacks details about error handling, shift behavior of other filters, and return value. Given no output schema and no annotations, more context (e.g., what happens if the index is out of bounds) would make it more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no parameter descriptions (0% coverage), so the description fully compensates by explaining each argument: source_name, filter_name, and filter_index (with the constraint '>= 0' and clarification that 0 equals first in chain). This adds substantial meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Reorder') and resource ('a filter within a source's filter chain'), clearly stating the tool's function. It distinguishes from sibling tools like set_source_filter_name or set_source_filter_enabled, which address other filter attributes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when reordering filters in a source's chain) but does not explicitly mention alternatives or conditions for exclusion. It lacks guidance on prerequisites or when another filter-related tool would be more appropriate.
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 plainly states the effect (enable/disable), but it does not disclose any side effects, reversibility, permissions, or implications of studio mode. For a simple boolean setter, this is adequate but leaves 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no extraneous words. It is front-loaded with the action and clear to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one boolean parameter, no output schema), the description is nearly complete. It does not explicitly reference the sibling getter, but the purpose clarity covers that distinction. However, a brief mention of the getter would enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no description for the 'enabled' parameter (0% coverage), but the description's 'Enable or disable' directly explains the boolean parameter's meaning. The parameter name is also self-explanatory, so the description effectively compensates for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Enable or disable') and the resource ('studio mode'), making the tool's purpose unambiguous. It also naturally distinguishes itself from the sibling tool 'get_studio_mode_enabled' by focusing on modification rather than retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 that there is a getter sibling, nor any prerequisites or context for when enabling/disabling studio mode is appropriate.
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 disclosure burden. It usefully discloses the pairing constraint ('must be set in pairs') and the value range (1-4096), which are important behavioral rules. However, it omits side effects (e.g., impact on ongoing recording/streaming), persistence, or response behavior, leaving the agent with incomplete 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise: three sentences, front-loaded with the core action, followed by essential constraints. Every sentence adds value and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite good conciseness, the description is incomplete for a 6-parameter mutation tool with no annotations and no output schema. It fails to explain null semantics, the relationship between fps_numerator and fps_denominator, potential side effects, or any prerequisites. The tool is more complex than the description acknowledges, leaving significant gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 adds meaningful context by explaining the width/height pairing rule and the numeric range for resolution fields. Yet it does not clarify the meaning of fps_numerator/fps_denominator, the null default semantics, or explicitly enumerate all pair groupings (e.g., output_width/output_height), which limits its compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Change') and identifies the exact resources affected: canvas/output resolution and FPS. This clearly distinguishes it from sibling getters like get_video_settings and other setter tools. The scope is immediately understandable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for using the tool—setting video resolution and FPS parameters. It does not explicitly name alternatives or exclusion criteria, but the pairing constraint and range hint at when to invoke it. A stronger statement about reading settings via get_video_settings would merit a 5.
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 bears the full burden of disclosing behavior. It only states that it starts recording and where files land, but fails to mention what happens if recording is already active (e.g., whether it errors, restarts, or is a no-op), any permissions required, or other side effects. This is a minimal disclosure that leaves important behavioral traits undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the action ('Start recording to disk') and immediately adds a useful pointer to where files land. Every word earns its place; there is no unnecessary padding or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, simple command with no output schema, the description is mostly complete. It explains the core action and the file destination, which are the most critical facts. However, it omits behavioral details like handling of an already-active recording, which could be relevant in context. Given the simplicity, this is a reasonable but not exhaustive description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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. Per the rubric, 0 params yields a baseline of 4. The description adds no parameter-related info, but none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Start recording') and the resource ('to disk'), using a specific verb that distinguishes it from sibling tools like toggle_record, stop_record, and pause_record. The reference to config_tools.get/set_record_directory also reinforces the disk-related purpose. This is a clear and differentiated purpose statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that this tool is used when the agent wants to begin recording to disk, which is a clear context. However, it does not explicitly mention when not to use it or compare it to alternatives such as toggle_record, which could lead to confusion about whether to use start_record or toggle_record. The guidance is inferred rather than stated.
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 behavioral disclosure. It only states the action without detailing side effects, idempotency, or prerequisites. For a mutation-like operation, this lacks important context such as what happens if the camera is already stopped or whether it affects other outputs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the action and resource without any wasted words. It is as concise as possible while being clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given 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), the description adequately defines the operation. The sibling context (start_virtual_cam, toggle_virtual_cam) helps ground the tool's role. However, it does not mention any return value or conditions, which slightly limits completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description need not explain parameter meaning. The schema is empty, and the description is sufficient. Per instructions, 0 params warrant a baseline of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Stop) and the resource (virtual camera). It distinguishes itself from sibling tools like start_virtual_cam and toggle_virtual_cam by specifying exactly what it 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage in the context of stopping the virtual camera, but it does not explicitly discuss when to use this tool versus alternatives like toggle_virtual_cam or start_virtual_cam. For a simple action, the purpose itself provides adequate guidance, but there is room for explicit alternatives.
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 burden for behavioral disclosure. It only says 'Add a new filter' and lists parameters. It doesn't disclose consequences (e.g., whether existing filters are unaffected), prerequisites (source must exist), error behavior for invalid kinds, or return value. The only added behavioral detail is that filter_settings is optional.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one purpose sentence plus a straightforward Args list. Every element contributes, no filler, and the structure is easy to scan. It earns its place entirely.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create operation with no annotations and no output schema, the description gives enough to understand the purpose and parameters, but omits behavioral context like return value, side effects, or prerequisites. That makes it adequate but not fully complete for an agent to confidently invoke without further investigation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. The Args section explains each parameter's role: source_name, filter_name, filter_kind (with pointer to get_source_filter_kind_list), and filter_settings (optional). This adds real meaning beyond the bare schema, though it lacks examples or format details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Add a new filter to a source,' which is a specific verb-resource pairing. It distinguishes this tool from sibling filter operations like remove_source_filter, set_source_filter_settings, and set_source_filter_enabled, making its 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The primary use case is explicitly stated: adding a new filter to a source. It also references get_source_filter_kind_list for filter_kind, giving a helpful cross-reference. However, it doesn't explicitly state alternatives or when not to use the tool, 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.
- 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 async-only limitation, which is useful. However, it doesn't mention potential error behavior on non-async inputs, return format, or any side effects, leaving some behavioral unknowns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the core purpose and then the key constraint. Every word earns its place; there is no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of a one-parameter getter and the existence of sibling setter tools, the description provides the essential context: what it gets and its primary limitation. It could be enhanced by mentioning what the returned field order represents, but overall it's sufficient for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, meaning the description adds no explanation for the input_name parameter beyond what the schema provides (a generic string). The description doesn't clarify what constitutes a valid input name or how it relates to async inputs, so it fails to compensate for the lack of schema detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get an input's deinterlace field order' clearly states the action (get) and the resource (input's deinterlace field order). It distinguishes well from siblings like set_input_deinterlace_field_order (setter) and get_input_deinterlace_mode (different property).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Async inputs only' provides a clear usage constraint, telling the agent when this tool is applicable. It doesn't explicitly mention alternatives, but the constraint is meaningful and helps select between related tools.
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 correctly implies a read-only listing operation and notes the optional restriction by input kind. It does not disclose details like whether the list is global or scene-specific, return ordering, or array structure, which for a simple getter is a minor 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence for the main action and one for the parameter. Every word adds value, with no redundancy or irrelevant detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no output schema, the description adequately states purpose and parameter behavior, but it does not describe the return structure (e.g., that it returns an array of input objects with names and kinds). This is a minor completeness gap given the tool's simplicity and the lack of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description compensates by explaining input_kind as 'Optional — restrict to one kind' and pointing to get_input_kind_list for valid values. This adds meaning beyond the bare schema property, though it stops short of giving concrete examples or enumerating possible values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('all inputs'), with concrete examples of source types (mic, capture card, browser source). It clearly distinguishes from related sibling tools like get_input_kind_list, which lists input kinds rather than inputs themselves.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (to list inputs) and provides guidance on the optional filtering parameter by referencing get_input_kind_list. However, it does not explicitly mention when not to use it or alternatives (e.g., get_special_inputs), leaving some usage context implicit.
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 must carry the burden of behavioral disclosure. It clarifies that the property is a 'dynamic list property' and gives an example, adding some context beyond the tool name. However, it does not mention return format, error behavior, or permissions, leaving gaps for a getter with no annotation safety signals.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief, front-loads the core purpose, and includes a well-organized Args docstring. Every sentence is informative, including the illustrative example, with no unnecessary filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter getter with no output schema, the description explains the tool's core function and parameter semantics adequately. However, it does not describe the structure or type of the returned items, nor any conditions where the request might fail, leaving moderate gaps for complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 provides terse one-line definitions for both parameters ('Name of the input', 'Name of the list property'), and the example 'displays' gives a concrete hint for property_name. Yet these largely restate the parameter names and do not elaborate on types or expected formats.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get the items of a dynamic list property on an input' with a concrete example ('available displays for a display-capture source'). This specifies both the action and the resource, distinguishing it from sibling tools like get_input_settings or open_input_properties_dialog.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context with the example of display-capture sources, implying when this tool is appropriate. However, it does not explicitly mention when not to use it or name alternative tools, stopping short of a full 'when/when-not' guide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral disclosure. It adds context by specifying 'current profile' and 'raw parameter', indicating no processing. However, it omits return type, error behavior (e.g., missing key handling), and whether values are strings or parsed types. For a simple read, this is partially adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences plus an Args list, front-loaded with the action. No wasted words; every component serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (2 required params, no output schema), but the description does not describe the return value or error semantics. Since there is no output schema, this omission is notable. However, for a straightforward read operation with clearly explained inputs, the description is largely sufficient for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides only titles with no descriptions (coverage 0%), so the description's parameter explanations are essential. It defines category with an example ('Output') and name as 'Parameter name within that category,' adding meaningful guidance beyond the schema. This fully compensates for the schema's brevity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Read') and the resource ('raw parameter from the current profile's .ini configuration'), distinguishing it from sibling set_profile_parameter and from higher-level getters like get_video_settings. The verb 'Read' and modifier 'raw' make the tool's function 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly address when to use this tool versus siblings like get_video_settings or set_profile_parameter. It implies read-only access to raw ini values, but lacks direct alternative references or exclusion criteria, leaving the agent to infer usage from the tool name and sibling 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?
With no annotations provided, the description carries the full burden. It states the operation is read-only and returns filters in chain order, which implies no side effects. However, it does not disclose what the returned list contains (e.g., names, kinds, enabled states) or behavior for missing/invalid source names. This is adequate but leaves 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first states the purpose, the second documents the argument. It is front-loaded and every word earns its place. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one parameter and no output schema, the description is adequate but incomplete. It does not describe the return format (e.g., an array of filter objects with fields like name, kind, enabled). Since there is no output schema, the description should give more clue about what 'list' returns. 'In chain order' suggests ordering matters, but no further detail is provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no descriptions, and the description adds 'Name of the source.' for source_name, which is minimal and largely tautological. The main description adds the nuance that the source can be an input or scene, giving some context. With only one parameter and no schema coverage, the description could have provided more detail on expected values or prerequisites.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'filters on a source', with the scope 'all filters' and 'in chain order'. It distinguishes from sibling tools such as get_source_filter (which retrieves a single filter's settings) and get_source_filter_kind_list (which lists filter kinds). This is a specific, 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 Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: use when you need to enumerate all filters applied to a source, and notes that sources can be inputs or scenes. It does not explicitly mention when not to use it or provide alternatives, but the sibling tool names contextually imply the distinction. A more explicit exclusion (e.g., 'for a single filter's settings, use get_source_filter') would make it a 5.
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 full burden and does disclose the important behavioral caveat 'No bounds checking.' However, it does not describe what happens on an out-of-bounds offset, whether errors can occur, or what the return behavior is.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the purpose, followed by the key 'No bounds checking' caveat and a minimal parameter list. Every sentence adds value with no redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter seek operation, the description provides the core semantics and a caveat, but it omits details about return values/error behavior and does not explicitly situate this against the absolute-position sibling. This leaves minor but real gaps for an agent deciding how to use and handle failures.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description compensates for the 0% schema coverage by explaining both parameters: input_name identifies the media input, and offset_ms is in milliseconds with negative values seeking backward. This adds semantic meaning beyond the bare integer/string schema fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Seek'), a resource ('media source'), and the key differentiator ('relative to its current position'). This distinguishes it from the sibling tool set_media_input_cursor, which implies absolute positioning.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'relative to its current position' phrasing gives clear context for when to use this tool, but it does not explicitly mention when not to use it or reference the alternative absolute-seek sibling. The 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?
With no annotations, the description carries the transparency burden. It discloses the key non-destructive behavior (does not delete source), which is valuable. It does not mention error handling, reversibility, or return values, 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. The parenthetical adds critical nuance efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter removal tool with no output schema, the description covers the core action and key nuance. It is missing details about return values, error conditions, and prerequisites, but these are less critical given the simple contract.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 provides the overall action that maps scene_name and scene_item_id to scene and item, but does not give explicit parameter details or constraints. The names are self-explanatory, adding limited value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Remove a scene item from a scene' with a specific verb and resource. The parenthetical '(does not delete the underlying source)' distinguishes it from input removal tools like remove_input or remove_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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it removes a scene item while preserving the source. This implies when to use it (to remove a reference from a scene) and when not (to delete the source). However, it does not explicitly name alternative tools or exclusion conditions.
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 clearly states that the action writes to disk, which is the primary side effect, but it does not disclose that the replay buffer must be running to succeed, nor any error behavior or output details. This is adequate but incomplete for a side-effecting 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It includes a helpful parenthetical clarifying the 'instant replay' concept, making it both concise and easy to understand.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers what the tool does but omits important contextual caveats such as the need for an active replay buffer or the output location. With no annotations and no output schema, this is a noticeable gap for an agent deciding whether to call this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 schema coverage is 100%. Per the rules, the baseline is 4, and no additional parameter information is needed. The description adds no parameter specifics, but none are required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Save') and resource ('replay buffer') and clarifies the action ('to disk') with the 'instant replay' context. It clearly distinguishes from siblings like get_replay_buffer_status and start_replay_buffer, which handle different aspects of the replay buffer lifecycle.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used to save a replay clip, but it does not explicitly mention prerequisites (e.g., the replay buffer must be active) or compare to alternatives. Sibling tools like start_replay_buffer and stop_replay_buffer exist, but no guidance is given on when to use this instead.
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 disclosing behavioral traits. It only states that a hotkey is triggered, without mentioning side effects, possible errors (e.g., hotkey not found), required application state, or whether the action is reversible. This is a significant gap for a mutation-like 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a one-sentence purpose statement followed by an Args list. It avoids redundancy, front-loads the key action, and every sentence/line serves a purpose. The length is appropriate for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter tool with no output schema, the description covers the core purpose and parameters. However, it lacks behavioral transparency (e.g., error handling, return value) and explicit usage alternatives. It is adequate but leaves out details that would fully round out the context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides brief explanations for both parameters ('hotkey_name' and 'context_name'), adding meaning beyond the input schema which only lists titles. Although sparse, it clarifies that 'context_name' is optional and specifies the role of 'hotkey_name', compensating for the schema's 0% description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Trigger a hotkey by its name.' This clearly distinguishes it from the sibling tool 'trigger_hotkey_by_key_sequence' by specifying the trigger method (name vs. key sequence). The pointer to 'get_hotkey_list' clarifies the source for valid names.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly gives usage context by instructing the user to see 'get_hotkey_list' to obtain valid hotkey names. However, it does not explicitly state when to use this tool versus 'trigger_hotkey_by_key_sequence' or mention any exclusions. The indication is clear but not fully 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?
With no annotations, the description carries the full burden. It explicitly states the two-step behavior (create and switch), but does not disclose error conditions like duplicate names, potential side effects on existing collections, or any required permissions. The core behavior is clear, but additional context is sparse.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that conveys both the primary action and the switching side effect without any fluff. Every word earns its place, making it highly concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description provides the essential behavior, including the switching side effect. It is sufficient for an agent to know when and how to invoke it. Some minor details about error handling are absent, but they are not critical for this simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 implies that 'name' refers to the name of the new scene collection, but it adds no constraints or format details. With only one self-explanatory parameter, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'create' with a clear resource 'scene collection', and additionally states the side effect 'and switch to it'. This makes it distinct from sibling tools like set_current_scene_collection, which only switches to an existing collection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys a clear use case: when a new scene collection is needed and should become active. It doesn't explicitly mention alternatives, but the combined create-and-switch action inherently distinguishes it from tools that list or switch collections, providing clear context without exclusions.
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 conveys a read-only list operation and adds a meaningful conceptual note about groups being scenes, but does not disclose return format, ordering, or potential limitations beyond the 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It front-loads the action ('List all groups') and adds only the essential clarifying note about OBS semantics.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list tool, the description is sufficient: it states the resource and the operation. The lack of an output schema is partially mitigated by the tool name and the verb 'list', which imply a list of group names, though an explicit return description would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 adds no parameter information since there are none to explain; the schema already covers 100% of the empty parameter set.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List all groups' with a specific verb and resource, and the parenthetical 'OBS treats groups as a special kind of scene' distinguishes this from the sibling get_scene_list tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when the agent needs group information, but it does not explicitly specify when to prefer this over get_scene_list or provide exclusion criteria. The special-scene note gives context, but no explicit 'use this instead of X' guidance is given.
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 transparency burden. It does disclose that OBS groups are 'broken under the hood', which is a useful behavioral warning. However, it does not describe the precise failure mode, return format, or side effects, leaving some ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence with a clear reference and a practical caveat. Every word earns its place; it is front-loaded and efficient, wasting no space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and no output schema. The description leverages the sibling reference to convey return semantics, and adds a warning about group behavior. It lacks explicit details on return structure or error cases, but for a getter with a clear analogy, it is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate for explaining the parameter. It clarifies that the tool is 'for a group', implying group_name identifies the group. But it does not specify the exact expected format, how to discover group names, or any constraints. Given the simple single string parameter, the inference is adequate, but not thorough.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is like get_scene_item_list but for a group, giving a specific verb+resource and distinguishing it from the sibling tool. It explicitly names the analogous tool, 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance by advising 'prefer nested scenes over groups where possible', implying when to use this tool and when to avoid it. It also references the alternative get_scene_item_list for non-group scenes. However, it does not explicitly state a when-not-to-use scenario beyond the preference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavior on its own. It clearly states a read-only list operation, but it does not clarify whether it operates on the current scene collection, nor does it describe the exact return structure beyond scene names and program/preview names. It lacks any note about side effects or error 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence, front-loaded with the main action, and every word is necessary. Zero fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 0-param, no-output-schema tool, the description covers the return values (every scene, current program and preview scene names) and is sufficient. Minor gap: it doesn't specify 'current scene collection' context, but this is inferable from the sibling tools. Given the minimal complexity, it is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, so the baseline is 4. The description makes no parameter claims, and there is nothing to compensate for.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' and identifies the exact resource: every scene, plus the current program and preview scene names. This clearly distinguishes it from sibling tools like get_current_program_scene or get_scene_collection_list, which have narrower or different scopes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used to retrieve a full scene list with the current program/preview names, but it does not explicitly discuss when to use this tool versus alternatives such as get_current_program_scene or get_current_preview_scene. No exclusions or alternative recommendations are provided.
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?
Discloses the key status fields returned, which is the core behavioral information. No side effects or prerequisite conditions mentioned, but as a status getter this is sufficient. Since no annotations exist, the description takes on the transparency burden and does reasonably well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, highly concise, front-loaded with the resource and then a list of metrics. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter getter with no output schema, the description lists all the information returned. Could be improved by specifying the response type, but the field list provides adequate completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes no parameters, so the description needs no parameter explanation. Baseline 4 for zero-parameter tools applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Describes exactly what it does: retrieves stream output status. Lists specific metrics (active/reconnecting, timecode, duration, congestion, bytes sent, frames) that distinguish it from sibling status tools like get_record_status or get_output_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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. There is a generic get_output_status sibling, and the description doesn't explain when to prefer this stream-specific version.
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 explains the FPS fraction format (fpsNumerator/fpsDenominator), which is valuable. However, it does not explicitly state that this is a safe read operation with no side effects, though the word 'Current' and the getter name strongly imply it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of about 20 words, front-loading the key information (current resolution and FPS) and adding a precise calculation note for the fractional FPS. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no parameters and no output schema, the description provides the essential information: what it returns and how to interpret the FPS fraction. It could be slightly more complete by explicitly naming the return fields (e.g., width, height), but the description is adequate for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema coverage is 100%. Per the rubric, 0 parameters yields a baseline of 4. The description adds no parameter details because none exist, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns current canvas/output resolution and FPS. The word 'Current' implies a read operation, distinguishing it from the sibling set_video_settings. It identifies the resource (video settings) and the specific data returned (resolution and FPS).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving current video settings, but does not explicitly mention when to use it versus set_video_settings or other alternatives. It relies on the tool name and conventional 'get_' prefix to convey its read-only purpose. No exclusions or alternative suggestions are 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 of behavioral disclosure. It discloses the 'studio mode only' constraint and the staging purpose, but it does not mention what happens if studio mode is disabled (e.g., error or no-op) or any return value/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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured. It leads with a clear, informative sentence, then an Args block with the parameter. There is no unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given 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 essential purpose and usage, and the 'studio mode only' caveat is key. It omits error handling details and prerequisites, but given the simplicity, the description is fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 includes 'Exact scene name' for the single parameter, which adds a precision qualifier beyond the schema's bare 'Scene Name'. However, it doesn't provide additional context like where to find valid scene names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Load a scene into Preview') with a resource (scene) and context (studio mode only). It distinguishes itself from sibling tools like set_current_program_scene by explicitly targeting Preview and mentioning the follow-up transition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: studio mode only, and it stages a scene before transitioning to Program via trigger_studio_mode_transition. This implies when to use the tool, though it doesn't explicitly name alternatives such as set_current_program_scene.
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 full burden of behavioral disclosure. It explains the effect (reorder z-order) and the index origin (0 = bottom of source list), but it does not disclose potential side effects, error behavior, or any constraints beyond the index being >=0. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the purpose statement, followed by a clear Args block that documents each parameter. There is no redundant or irrelevant content; every sentence adds necessary value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given 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, the description adequately covers the operation and parameters. It is mostly complete, but it does not mention preconditions (e.g., the scene and item must exist) or the relationship to get_scene_item_list for obtaining valid IDs. Given the low complexity, this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 provides a concise explanation for each parameter (scene_name, scene_item_id, index), including the constraint '>= 0' and the interpretation of 0 as the bottom of the source list. This meaningfully supplements the bare schema, though it could go further by noting how to obtain valid scene_item_id values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Reorder a scene item's stacking position (z-order).' It clearly distinguishes this tool from siblings like get_scene_item_index (which retrieves the index) and set_scene_item_transform (which changes transform, not order).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when you want to change an item's z-order, but it does not explicitly state when to use it vs alternatives, nor does it mention any exclusions or prerequisites. It lacks explicit guidance on when this tool is preferred over related operations.
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 does disclose that the tool returns the saved file's path, which is useful. However, it does not mention prerequisites (e.g., must be actively recording), failure behavior, or whether the recording is finalized automatically, leaving gaps in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences that are front-loaded with the essential action and return value. Every word earns its place, with no unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no params, no output schema), the description is largely complete: it states the action and the return value. It does not address edge cases like stopping when no recording is active, but for a basic stop operation this is likely sufficient. The sibling list provides additional context about recording-related tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is vacuously complete. Baseline for 0 params is 4, and the description adds no parameter information because none is needed. This is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Stop recording' with a specific verb and resource, and it distinguishes itself from siblings like start_record and toggle_record. The addition of 'Returns the saved file's path' provides extra clarity about 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 Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use stop_record versus alternatives such as toggle_record or pause_record. The usage context is implied by the action itself, but no explicit guidance or exclusions are 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?
No annotations are provided, so the description carries full responsibility. It discloses that the duplicate preserves transform/crop and can target a different scene, which is useful. However, it does not specify whether the source is referenced or copied, what other properties are duplicated (e.g., filters, enabled state), or what the tool returns. This is partial but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well structured: a one-sentence summary followed by a clean Args block. No filler or redundant text, and the core action is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description must explain the return value and side effects. It does not mention what the tool returns (e.g., the new scene item ID) or any failure conditions. Although the parameters are well described, the missing result information leaves the description incomplete for an agent that needs to chain operations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no descriptions for parameters (0% coverage), but the description's Args section fully explains each parameter: scene_name (current scene), scene_item_id (numeric ID), and destination_scene_name (target scene, defaulting to source). This completely compensates for the schema gap and adds precise semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Duplicate a scene item, copying its transform/crop, optionally into a different scene.' It identifies the specific action (duplicate) and resource (scene item), and the detail about copying transform/crop distinguishes it from sibling tools like create_scene_item or set_scene_item_transform.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by indicating the tool is for duplicating an existing scene item and optionally moving it to another scene. However, it does not explicitly contrast with alternatives like create_scene_item or mention exclusions, so it lacks the full when-not-to-use guidance required for 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?
The description discloses a key behavioral trait: it returns 1.0 when no transition is active, which is not obvious. With no annotations provided, this adds necessary transparency. However, it does not explain what the cursor represents during an active transition (e.g., 0.0 at start, 1.0 at end), though the range implies this. The description goes beyond the bare 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no wasted words. It front-loads the core information (current transition progress) and includes the special case (no transition active) efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter getter with no annotations or output schema, this description is complete. It states the return range and the special no-transition behavior, which is all an agent needs to invoke the tool correctly and interpret its result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 explain parameter semantics. The baseline score of 4 for no parameters is applied, since the description cannot add meaning beyond what the empty schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the resource (current scene transition cursor) and its value range (0.0-1.0). It distinguishes from sibling getters like get_current_scene_transition, which likely returns the transition name, by focusing on progress. The verb 'get' is implicit in the tool name, but the description effectively communicates what the tool returns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool vs. alternatives. The description does not mention related tools like set_current_scene_transition or set_tbar_position, nor provide context on polling or transition states. It simply states what it returns, leaving the agent without 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?
With no annotations provided, the description carries the full burden of disclosing behavior. It communicates that the tool lists all configured transitions and marks the current one, which is useful. However, it does not disclose return format, ordering, or any potential edge cases. The description is adequate for a simple read-only list but lacks additional behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the main action ('List every configured transition') and important detail ('which one is current'). There is no filler or repetition, 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.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no params, no output schema), the description states the core purpose but does not specify the structure of the return value. It does not clarify whether the list is an array of strings, objects, or how the current transition is identified. Since there is no output schema, the description should provide more return-value detail to be complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema is empty with 100% schema coverage. Per the rubric, a baseline of 4 applies for zero-parameter tools. The description does not need to add parameter information, and the absence of parameters is consistent with the described behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('List') and resource ('every configured transition'), and adds the distinguishing detail that it indicates which transition is current. This differentiates it from sibling tools like get_transition_kind_list (which lists available types) and get_current_scene_transition (which retrieves only the current 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/5Does 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 see all configured transitions and identify the current one. It does not explicitly mention alternatives or exclusions, but the self-contained use case is unambiguous. Given no explicit when/when-not guidance, it falls short of a 5 but is more than implied usage.
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 disclosure burden. It explains the two distinct visibility states (videoActive vs. videoShowing), which clarifies likely behavioral nuance and source type scope. However, it does not mention return format or error 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences and an Args list, with no fluff. It front-loads the core purpose and clearly documents the parameter. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains what the tool checks but lacks explicit return value details (e.g., whether it returns a single boolean or an object with videoActive/videoShowing). With no output schema, this is a notable gap for a getter tool, though the simple parameter and clear purpose compensate partially.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only specifies source_name as a required string. The description adds meaning by stating it is the name of the input or scene, which is essential context since schema description coverage is 0%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks whether a source is showing in Program (videoActive) and/or visible in the UI (videoShowing). It specifies the resource (source, which includes inputs or scenes) and the action, distinguishing it from sibling tools that handle other source properties.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does 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 need to know if a source is active or visible) but does not explicitly state alternatives or exclusions. It lacks guidance on when to prefer this over related tools, though the unique purpose is fairly 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 carries the full burden for behavioral transparency. It discloses the scope ('every transition kind this OBS install supports') and gives examples, but does not state output format, ordering, or error behavior. For a simple read-only list, this is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with examples. Every word earns its place; 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.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With zero parameters and no output schema, the description fully communicates what the tool returns: a list of supported transition kinds. The examples make the return value concrete, making the tool self-contained for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the baseline is 4. There are no parameter semantics to document, and the description appropriately omits any parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' and identifies the resource: every transition kind supported by this OBS install, with concrete examples (Cut, Fade, Stinger). This clearly distinguishes it from siblings like get_scene_transition_list, which lists configured transitions rather than supported kinds.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternative guidance is provided. The phrase 'this OBS install supports' implies use when enumerating available transition kinds, but it does not mention alternatives such as get_scene_transition_list or explain when not to use this tool.
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 full burden. It discloses that the response includes a connection-specific list of requests, which is a useful behavioral detail. However, it does not explicitly state that the operation is read-only or side-effect-free, though the name and content strongly suggest a pure retrieval.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence front-loaded with the core subject. It avoids any repetition of the tool name and every word adds value by specifying the exact contents of the response.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given 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, simple read operation), the description fully explains what the agent will receive: version info, platform, and available requests. It is complete for both selection and invocation purposes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema is empty, so the baseline is 4. The description is not required to explain parameter behavior because no parameters exist, and it correctly avoids adding irrelevant details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies what the tool returns: OBS/obs-websocket version info, platform, and available requests. It is specific and unambiguous, and it distinguishes itself from sibling tools by being the only version-related introspection tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by naming the exact data returned, but it does not explicitly state when to use this tool or mention alternatives. It provides no exclusions or prerequisites, leaving the usage context 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.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It explains the non-obvious 'release' semantics, which adds value. However, it does not disclose side effects, whether it is a read or write operation, or the consequences of setting release=False without a subsequent update.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately brief: one purpose sentence followed by a structured Args block. It is front-loaded with the main purpose and contains no unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter tool with no output schema, the description covers the essentials: what it does, the parameter ranges, and the special release behavior. A minor gap is the lack of explicit clarification on what happens if release is set to False but no subsequent update follows, but overall it is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does 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 effectively: 'position' range is given as 0.0-1.0, and 'release' is explained with conditional usage. This adds meaningful domain context beyond the bare schema types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Set the T-bar position' with a specific purpose 'for manual transition scrubbing', using a specific verb and resource. It distinguishes itself from sibling transition-related tools like 'trigger_studio_mode_transition' or 'set_current_scene_transition_duration'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for manual transition scrubbing and provides guidance on the 'release' parameter ('Set False only if you're about to send another position update immediately after this one'). However, it does not explicitly state when to use this tool versus alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the burden. It discloses the mutation (adding a marker) and a version/format constraint. However, it does not mention error behavior when recording isn't active or when format is unsupported, nor side effects beyond the marker.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus a one-line argument explanation. It is front-loaded with the action and contains no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given 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 annotations or output schema, the description provides the action, parameter semantics, and a key compatibility constraint. It is largely complete, though it doesn't address error handling or return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only provides type and default, but the description explains 'chapter_name' is an optional name for the marker. This adds meaning by clarifying optionality and purpose, compensating for 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Add a chapter marker to the file currently being recorded' with a clear verb and resource. It distinguishes from sibling recording tools by specifying the marker action and adds a format/version constraint.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: use it on the file currently being recorded, with a specific limitation ('Only supported on Hybrid MP4 output as of OBS 30.2.0'). It doesn't name alternatives, but no direct alternative exists for chapter markers.
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 full burden of behavioral disclosure. It explains the meaning of 'Program' and implies a read-only operation via the 'get' verb, but it does not specify the return format, potential errors, or any other behavioral details. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise phrase with no redundant words. Every word adds meaning, particularly the parenthetical clarification that makes the purpose explicit.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given 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), the description provides enough context to select and invoke it correctly. It could optionally state the return value more explicitly, but the meaning is already clear from the name and description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema shows no properties, so there is nothing for the description to explain. The baseline for 0 params is 4, and the description correctly avoids adding unnecessary parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource (current Program scene) and the action (get it via the 'get' verb implied in the name). The parenthetical '(what viewers see)' distinguishes it from the Preview scene, making it unambiguous and distinct from siblings like get_current_preview_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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'what viewers see' provides clear context for when to use this tool—specifically when the live Program scene is needed rather than Preview. It does not explicitly name alternatives or exclusions, but the context is sufficient for an agent to infer the correct use case.
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 full burden of behavioral disclosure. It states the tool lists connected monitors, which is a read-only operation by implication ('list'). However, it does not describe the output format, whether monitor IDs are returned, or any other behavioral details. This is a minimal but not misleading description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with the key verb first and a helpful parenthetical. It is appropriately sized and front-loaded with the action, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no parameters and no output schema, the description is mostly complete: it names the resource and the intended use. It could be slightly more explicit about what the output contains (e.g., monitor IDs usable in projector tools), but the parenthetical strongly implies this. No significant gaps given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and schema description coverage is effectively 100%. Per rubric, 0 parameters gets a baseline of 4. There is no parameter information to add, and the description does not need to compensate for any gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' with the resource 'connected monitors', making the tool's function unambiguous. The parenthetical '(for opening a projector on one)' adds a clear use case that distinguishes it from other list tools like get_scene_list or get_transition_kind_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does 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 (when you need to open a projector on a specific monitor), but it does not explicitly mention alternatives or exclusions. The intended use is implied by the parenthetical, which is helpful but not a full usage guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavioral traits. It indicates the stats are 'live' and lists the metrics, implying a read-only operation. However, it does not explicitly confirm no side effects, permissions required, or the fact that it may only be relevant during streaming. This leaves some gaps, so 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, information-dense sentence that lists the stats types and a use case. It is front-loaded with 'Live perf stats' and contains no wasted words, 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.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no input parameters and no output schema, the description covers the key content (CPU/memory, FPS, skipped frames, disk space) and its purpose. It does not specify exact return formats or units, but it is complete enough for an agent to understand its function and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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%. With no parameters to explain, the description does not need to add parameter semantics. The baseline of 4 for zero-parameter tools fits here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool provides live performance stats (CPU/memory, FPS, skipped frames, disk space), which distinguishes it from sibling tools like get_output_status or get_stream_status. The verb 'get' and resource 'stats' are explicit, and the list of metrics leaves 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 Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a specific use case: 'Use to check for dropped-frame problems mid-stream.' This provides clear context for when to use the tool, but it does not explicitly mention alternatives or situations where it should not be used, which would merit a 5.
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 behavioral burden. It explains the two modes (fullscreen/windowed) and parameter effects, but it does not disclose potential side effects, whether this is a blocking UI operation, or what the return value/behavior is after invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a one-sentence summary followed by a minimal args list. Every sentence serves a purpose with no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple UI action with three parameters and no output schema, the description fully covers the input semantics and behavior. It explains what the tool does and how each argument affects the resulting projector.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no property descriptions (0% coverage), so the description's Args section fully compensates by explaining source_name, monitor_index, and projector_geometry with their roles and defaults. This adds significant meaning beyond the schema's type/title/default fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb + resource: 'Open a fullscreen or windowed projector for a specific source.' It clearly defines the tool's purpose and distinguishes it from sibling tools like open_video_mix_projector by focusing on source projection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: use this tool to display a source as a projector. However, it does not explicitly state when to prefer this over alternatives like open_video_mix_projector, nor does it mention any exclusions or prerequisites.
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 bears the full burden. It discloses the operation, the offset range, and the purpose, but does not mention potential side effects, error conditions, persistence, or whether permissions are required. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus a compact Args list. It front-loads the purpose, then clearly documents parameters. No filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with two primitive parameters and no output schema, the description is mostly complete. It covers what the tool does, when to use it, and parameter semantics. It could additionally mention the companion getter or error behavior, but the tool is straightforward.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description compensates by defining both parameters: 'input_name: Name of the input' and 'offset_ms: Offset in milliseconds, range -950..20000'. This adds meaning beyond the schema's type-only definitions, including a useful range constraint.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Set an input's audio sync offset', and adds the purpose 'use to fix audio/video drift'. This clearly distinguishes the setter from the sibling getter (get_input_audio_sync_offset) and other input-related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear usage context: 'use to fix audio/video drift'. It implies an alternative (the getter) but does not explicitly name it or state when not to use this tool. The guidance is present but not exhaustive.
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. It discloses the core mutation behavior ('Set') and the range constraints for both volume parameters, but does not mention return values, error behavior, or what happens if both parameters are supplied (despite saying 'exactly one').
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, uses a clear 'Args:' format, and front-loads the action. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 3-parameter setter with no output schema, the description covers the purpose, parameter meanings, ranges, and the key constraint. It lacks explicit error handling details but is sufficient for correct invocation in most cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only lists parameter names and types; the description adds the meaning of each parameter, including the dB range (-100..26) and linear multiplier range (0..20), and the mutual exclusivity requirement, which is not present in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Set') and resource ('input's volume'), clearly distinguishing it from sibling tools like get_input_volume. The 'pass exactly one' clause further clarifies its 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for use (setting input volume) and specifies the parameter constraint, but does not explicitly contrast with alternative tools or state when not to use it. The sibling list includes many audio tools, but no explicit guidance is given.
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 of behavioral disclosure. It prominently states 'No bounds checking,' which warns that invalid positions may not be caught. This is a valuable behavioral trait, though it does not describe return values or error handling in detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with the core action in the first sentence and the key caveat in the second. The parameter list is logically placed and tightly written. No wasted words or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple seek operation, the description covers the action and parameters, but does not mention return value, failure modes, or prerequisites (e.g., that the input must be a media input). The 'No bounds checking' hint is useful, but without annotations or output schema, the description could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no descriptions for the two parameters (0% coverage). The description compensates fully with an 'Args' section that explains both `input_name` and `cursor_ms` clearly, including the unit for cursor_ms (milliseconds). This goes beyond the structured schema, which only lists types and titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies a seek operation to an absolute position on a media source, with a distinctive caveat about bounds checking. It implicitly distinguishes itself from the sibling tool 'offset_media_input_cursor' by emphasizing absolute positioning, making its purpose clear and non-overlapping.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives context that this is for absolute seeking, which implies that relative seeking would use the offset sibling, but it does not explicitly state when to use this tool over alternatives or provide exclusions. Guidance remains 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 burden. It discloses the JSON-serializability constraint and provides a meaningful use case, but it does not state overwrite behavior, persistence lifetime, or error consequences. This is adequate but incomplete for a write 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus a clearly formatted argument list. Every sentence adds value, and the structure is front-loaded with the core purpose. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given 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, the description gives enough context: what it does, the data type, and a use case. It could mention that it overwrites existing slots or that it returns nothing, but the core is covered. Sibling get_persistent_data completes the picture.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the argument list compensates well. It explains realm's allowed values, slot_name's purpose, and clarifies slot_value can be any JSON-serializable value (though the schema says string, which could imply stringified JSON). This adds strong meaning beyond raw parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Set') and resource ('value in an OBS persistent-data slot'), and the example of storing giveaway winners distinguishes it from sibling get_persistent_data. This is a specific, non-tautological statement of 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear use case: 'useful for storing state the AI needs to remember across tool calls' with an example. It implies when to use versus get_persistent_data but does not explicitly name alternatives or exclusions, so it loses one point.
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. It states the core action and rationale but does not disclose prerequisites (e.g., must be recording), side effects on the existing file, or error conditions. Some transparency exists but gaps remain.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the action and rationale without any wasted words. Perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given 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), the description adequately covers what it does and why. It lacks edge-case details like requirements for an active recording, but for a simple action this is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the input schema is trivially complete. The description does not need to elaborate on parameter semantics, earning the baseline score of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Split the current recording') and the resource ('into a new file'), making it distinct from sibling tools like create_record_chapter. The verb 'split' 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 Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a clear use case: 'useful for keeping individual segments a manageable size on long streams.' This implies when to use the tool but does not explicitly mention alternatives or exclusions compared to related record 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?
No annotations are provided, so the description carries the burden. The word 'Get' clearly implies a read-only operation with no side effects, and the description explicitly states the return format (linear multiplier and dB). It does not discuss error handling or special cases, but for a simple getter this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no wasted words. It front-loads the verb and resource and includes the key return information compactly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple getter with one parameter and no output schema. The description fully conveys what the tool does and what it returns. Given the tool's low complexity, no additional context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema's only parameter is input_name with no description, and schema coverage is 0%. The tool description says 'an input's volume', which implies the parameter identifies the target input. The parameter name is self-explanatory, and the description provides enough context to understand its role.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the resource ('an input's volume'), and specifies the return format as both a linear multiplier and dB. This distinguishes it from sibling tools like get_input_mute (which gets a different property) and set_input_volume (which writes).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The verb 'Get' implies this is for reading volume, and sibling set_input_volume exists for writing. However, the description does not explicitly mention when to use this tool versus alternatives or provide any exclusions or prerequisites.
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 must carry the burden of explaining behavior. It conveys that this is a listing (read-only) operation and specifies the scope ('every registered output') with useful type enumeration. However, it does not explicitly state non-destructiveness or describe the return format, leaving some gap given the absence of annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is front-loaded with the verb and resource, followed by a parenthetical enumeration of output types. Every word earns its place; no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list tool, the description is fully complete. It states what is listed (registered OBS outputs) and clarifies the categories. No output schema exists, but the tool's purpose is entirely clear and the description suffices.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is empty. Per the baseline for 0 params, the description does not need to add parameter semantics. The description adds no param-related info, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' and clearly identifies the resource ('registered OBS output'), enumerating the key output types (stream, record, virtualcam, replay buffer) and plugin-added outputs. This distinguishes it from sibling tools like get_output_status or toggle_output, which target individual outputs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies use when the agent needs a full inventory of outputs, with no exclusions. However, it does not explicitly name alternatives like get_output_status for individual output details, so it lacks explicit when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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 for behavioral disclosure. It implies a read-only operation by listing status fields without mentioning side effects, but it doesn't explicitly state that the tool does not modify anything or describe behavior when recording is inactive. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the resource name (record output) followed by a concise list of returned fields. Every word is informative and there is no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no parameters and no output schema, the description is complete: it names the resource and enumerates the exact data returned. There is no missing context that would prevent correct invocation or interpretation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the input schema is empty, so there is nothing to document. The baseline score of 4 is appropriate because the description correctly focuses on the return value instead.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that this tool retrieves the status of the record output, listing specific fields (active, paused, timecode, duration, bytes written). This makes it distinct from sibling tools like get_output_status or get_stream_status, which focus on other output types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does 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: to check the current status of the recording output. It does not explicitly mention alternatives or exclusions, but the resource being 'record output' is unambiguous among the 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 provided, the description carries the full burden. It clearly states the output includes all collections and the active one, leaving no misleading impression of side effects. It does not explicitly say 'read-only' but the list verb implies no mutation, which is acceptable for this simple getter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It efficiently conveys the full purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with no output schema and no annotations, the description sufficiently tells the agent what to expect: all scene collections plus the active one. No additional context seems necessary for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and the schema coverage is trivially 100%. The baseline of 4 for zero parameters applies; the description is not required to explain any parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does 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 ('scene collections') and adds the detail about the currently active one. It is clearly distinguished from sibling 'get_scene_list', which lists scenes within a collection, not collections themselves.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: use when you need to see all scene collections and the current one. However, there is no explicit mention of when not to use it or alternatives like 'set_current_scene_collection' or 'create_scene_collection'. The distinction from 'get_scene_list' is left to the tool name rather than described.
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 states this is a simple enumeration of names, implying a read-only operation, but does not explicitly mention that it has no side effects or what happens in edge cases (e.g., if no special inputs exist). For a trivial 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff. The first sentence delivers the core purpose, and the second adds a usage tip. It is front-loaded and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter getter, the description is complete: it lists the exact names returned and explains the intended usage. No output schema exists, but the description itself enumerates the expected return values, making the tool fully understandable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is nothing to describe. The schema coverage is vacuously 100%. Per the baseline for 0 parameters, a score of 4 is given. The description does not need to add parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the names of built-in special audio inputs, enumerating them as 'Desktop Audio 1/2, Mic/Aux 1-4'. This distinguishes it from sibling tools like get_input_list, which lists broader input sources. The verb 'get' in the tool name combined with 'Names of...' makes the purpose explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case: 'Use these names to control the default audio channels.' It tells the agent when to use the tool (when needing identifiers for built-in audio inputs) but does not explicitly state when not to use it or mention alternatives. This is clear context without exclusions, so a 4 is appropriate.
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. It discloses a conditional behavior (only applies when the transition is not fixed-duration) and the accepted range, but does not state what happens if the transition is fixed-duration or describe side effects/errors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with the purpose first and an Args block below. There is no padding or redundant restatement of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter setter with no output schema and no annotations, the description covers purpose, applicability, units, and range. It only lacks explicit behavior when the transition is fixed-duration, which is a minor gap at this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only provides the type (integer), with no description (0% coverage). The description fully compensates by specifying units ('milliseconds') and the valid range (50-20000), giving the agent complete parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Set') and identifies the exact resource ('duration of the current transition') with a scope caveat ('if it isn't fixed-duration'). This clearly distinguishes it from sibling transition tools like set_current_scene_transition_settings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It states when the tool is applicable (non-fixed-duration transitions) and implies when not to use it (fixed-duration ones). It does not explicitly name alternatives, but this is a narrow setter and the condition is clear guidance.
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 disclosure burden. It explains the effect (override on switching into the scene), the meaning of None to clear, and a valid duration range (50-20000 ms). However, it does not mention error behavior, permissions, or side effects on existing overrides.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: a single sentence explaining the purpose, followed by a focused Args list. Every line adds value, especially the None-to-clear semantics for both optional parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with three parameters, the description covers purpose, all parameters, and null semantics. It does not specify return values or error handling, but that is secondary for this type of operation. Given the absence of annotations and output schema, the description handles the essentials well.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description's Args section is essential. It defines each parameter and adds meaning beyond the schema: scene_name identifies the target scene, transition_name can be None to clear the override, and transition_duration_ms has a range and can also be None to clear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'override' and clearly identifies the resource: the transition used when switching INTO a specific scene. It explicitly contrasts with the 'global current transition', which differentiates it from sibling tools like set_current_scene_transition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does 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: to set a per-scene override instead of the global transition. However, it does not explicitly name alternatives or state when not to use it, only implying the contrast with global transition setters.
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 disclosure. It clearly explains the filter order and why, states that existing filter kinds are skipped to avoid duplication, and notes that this is a one-shot setup. It does not cover failure modes or what happens if an existing filter has different settings, but the core side effects are transparent and reversible via the referenced removal 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with an overview, behavioral notes, and a detailed parameter list. It is longer than average because it must document 9 params without schema help, but every sentence adds value and the main purpose is front-loaded in the first sentence. The structure makes it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 9 params, no annotations, and no output schema, the description provides a remarkably complete picture: what it does, the chain order, dedup behavior, defaults, and parameter semantics. It stops short of error handling or edge cases, but for a setup utility this is sufficient and unlikely to leave the agent guessing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Since schema description coverage is 0%, the description fully compensates by giving each parameter purpose, units, ranges, defaults, and tuning guidance (e.g., 'Should sit slightly below your voice level', '5-8 dB below open threshold'). This goes far beyond the bare schema titles and provides actionable context for choosing values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the action ('Set up a standard mic-cleanup filter chain'), the resource ('mic/audio input'), and the exact composition ('Noise Gate -> Noise Suppression -> Compressor'). This clearly distinguishes it from sibling tools like create_source_filter or remove_source_filter, as it is a one-shot setup rather than a single-filter 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly indicates when to use the tool ('in one call' for a standard chain) and explicitly notes that removing a stage later is done via remove_source_filter, giving an alternative. However, it does not explicitly contrast with using create_source_filter for individual filter setup, so it lacks an explicit when-not scenario beyond the removal case.
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 transparency burden and clearly states a read-only listing behavior ('List all canvases'). It goes beyond a bare statement by disclosing that most setups have only the main canvas, which informs expected results. It does not detail return format, but for a simple list tool this is not 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the core action ('List all canvases in OBS') and followed by a concise parenthetical note. Every word contributes meaning, with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given 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 adequately conveys purpose and situational context, including the nuance about most setups only having a main canvas. It could optionally describe the return shape, but the tool is simple enough that this omission does not prevent correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the input schema confirms this, so no parameter explanation is needed. The description adds no parameter-specific detail, but the baseline for zero-parameter tools applies. Schema coverage is 100% and there is nothing to clarify.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List all canvases in OBS', which identifies the specific verb (list), resource (canvases), and scope (all in OBS). The parenthetical about multi-canvas adds useful context without obfuscating the primary purpose. It inherently distinguishes from sibling tools like get_scene_list or get_input_list by naming the resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context by noting multi-canvas is a newer OBS feature and that most setups only have the main canvas, helping the agent understand when this tool might be relevant. It does not explicitly name alternatives or exclusions, but the context is sufficient for a zero-parameter listing tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations were provided, so the description carries the burden. It discloses the return contents (kind, duration, fixed-duration, settings) and implies a read-only operation via the 'get' verb. It does not mention error conditions (e.g., when no scene is active) or return structure, but for a simple getter, the listed fields provide useful behavioral insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the main purpose ('Full detail on the current transition') and then lists the specific fields. 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.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (zero params, no output schema), the description effectively communicates the main return fields. It could have clarified that 'settings' is a map of transition-specific properties or mentioned potential edge cases (e.g., null when no transition), but for a basic getter, the provided detail is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is trivially complete. Baseline for zero params is 4. The description adds value by indicating what the returned data will contain, even though no input semantics are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: retrieving full detail on the current scene transition, specifying the exact data elements (kind, duration, fixed-duration, settings). This distinguishes it from sibling getters like get_scene_transition_list (which lists all transitions) and get_current_scene_transition_cursor (which only gets the cursor position).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies its use case: when you need current transition details. It does not explicitly state alternatives or when not to use it, but the name and context make it clear. Given the sibling setter tools (set_current_scene_transition), the agent can infer this is the corresponding getter. No exclusions are needed.
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 clarifies the enabled parameter's meaning, which is helpful, but it does not disclose any side effects, return values, or required permissions. For a simple setter, 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with a clear one-line purpose followed by a compact Args list. Every sentence serves a purpose, and there is no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (3 required parameters, no output schema, no annotations), the description covers all essential information: what the tool does, what parameters to pass, and what the boolean means. Nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema properties have no descriptions (0% coverage), and the description fully compensates by explaining each parameter: scene_name, scene_item_id, and enabled with explicit boolean semantics. This adds significant value beyond the structured schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with 'Show or hide a scene item,' which is a specific verb+resource pair that clearly differentiates this tool from siblings like set_scene_item_locked or get_scene_item_enabled. The purpose is 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies use for setting visibility of a scene item, and its parameter explanations support correct usage. However, it does not explicitly mention alternatives or exclusions, though the context makes it 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, the description discloses a key behavioral trait: the request is best-effort and less reliable than dedicated requests. This warns the agent about potential incompleteness or unreliability, which is valuable for a simple list 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no fluff. The main action is front-loaded, and the reliability caveat is useful context. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter, no-output-schema listing tool, the description is complete. It explains what the tool returns (hotkey names) and the important reliability caveat, making it sufficient for an agent to decide when to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is fully covered. The description adds context about the output (hotkey names) and the reliability caveat, which is sufficient given no parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all hotkey names in OBS, with a specific verb and resource. It distinguishes from sibling tools like trigger_hotkey_by_name and trigger_hotkey_by_key_sequence by focusing on listing names, not triggering.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a usage guideline by warning that hotkey requests are less reliable than dedicated requests, implying this tool should be used when no dedicated request exists. It doesn't name alternatives explicitly, but the contrast is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden. The verb 'List' and resource 'filter kind' clearly imply a non-destructive, read-only operation. Examples of filter kinds give the agent a preview of the output format and expected values, though it does not explicitly state return type or side effects (though none are expected).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence containing the essential information: verb, resource, scope, and examples. No unnecessary words or repetition, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple parameterless enumeration, the description is complete: it states that the tool returns the list of supported filter kinds for this OBS install and offers examples to clarify the content. Even with no output schema, the return value is clearly implied.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 there are no parameter details to convey. Baseline 4 for zero-param tools is appropriate; the description rightly omits parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('filter kind') with clear scope ('every... this OBS install supports'). It distinguishes from sibling tools like get_source_filter_list (which lists actual filters on a source) and get_input_kind_list (input kinds), and provides concrete examples.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The purpose statement implicitly tells the agent when to use this tool: whenever the supported filter kinds for the current OBS install are needed. It does not explicitly exclude alternatives, but the context is clear, and sibling names provide contrast that reduces ambiguity.
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 side effects. It states that the tool 'Cuts Preview to Program,' which is a meaningful behavioral outcome. It doesn't mention prerequisites (e.g., studio mode must be enabled) or failure modes, but the studio mode reference partially implies this 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, immediately front-loaded with the action and then enriched by the 'same as clicking' analogy and the effect. Every word earns its place with no redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless action with no output schema, the description fully covers what the tool does, how it behaves, and the context (studio mode). The analogy to the Transition button makes the usage unambiguous, and the effect is clearly stated, making it complete for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the schema is trivially complete. The description adds no parameter information, but per the rubric, a zero-parameter tool receives a baseline score of 4, which is appropriate here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Trigger') and resource ('the current transition'), immediately clarifying the action. It distinguishes from siblings like set_current_scene_transition and get_studio_mode_enabled by referencing the studio mode Transition button and the effect ('Cuts Preview to Program').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by likening the tool to clicking the Transition button in studio mode, which implies when it should be used. It doesn't explicitly state exclusions or alternatives, but the analogy effectively communicates the intended use case among a crowded set of transition-related 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 provided, the description carries the burden. It discloses that the tool returns a Base64-encoded screenshot, implying a non-destructive read operation. Parameter constraints (ranges, defaults) add transparency. It doesn't explicitly state non-destructive or error behavior, but the core 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is succinct and well-structured with a brief intro and an Args list. Every sentence adds value, covering purpose, format reference, and parameter details without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description explains the return format (Base64), all parameters, and cross-references get_version for format validation. It is sufficiently complete for a screenshot tool with 5 parameters and no nested objects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description explains every parameter in detail: source_name (input or scene), image_format with examples, optional image_width/height with range and omission behavior, and compression quality with range and -1 default. This adds significant meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does 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 Base64-encoded screenshot of a source (input or scene)'. It specifies the resource (source) and output format (Base64), and distinguishes from sibling tools like save_source_screenshot by emphasizing the encoded return.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'use this to actually SEE what's on stream' provides a clear use case. It also directs users to get_version for valid image_format values, which is helpful. However, it doesn't explicitly mention when not to use it or contrast with save_source_screenshot, though the Base64 return implicitly differentiates it.
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 explains the two operating modes (fullscreen/windowed), the meaning of monitor_index -1, and the mutual exclusivity constraint. It lacks side-effect details like whether existing projectors are replaced, but it exceeds minimal expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a single introductory sentence followed by an Args block. Each line adds essential information without fluff, and the format is easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter tool with no output schema or annotations, the description covers all necessary invocation details: parameter options, mode behavior, mutual exclusivity, and a cross-reference to get_monitor_list. It provides complete guidance for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does 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 thoroughly explains each parameter: video_mix_type values, monitor_index semantics including the -1 sentinel, and projector_geometry format with mutual exclusivity. This adds substantial meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Open a fullscreen or windowed projector for Preview/Program/Multiview.' The verb 'open' and resource 'projector' are specific, and mentioning 'Preview/Program/Multiview' distinguishes it from sibling tools like open_source_projector.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for parameter usage, including monitor_index -1 for windowed mode and the mutual exclusivity with projector_geometry. However, it does not explicitly state when to use this tool over alternatives like open_source_projector, so it stops short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It states 'Write' (mutation) and clarifies that None deletes the parameter. However, it does not mention potential side effects such as whether changes require a restart, whether invalid parameters are silently ignored, or whether the profile file is modified immediately. For a low-level config writer, this leaves 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact—two sentences of purpose/guidance followed by a concise Args list. Every sentence earns its place, with the purpose and usage guideline front-loaded. No redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with three required parameters and no output schema, the description covers what it does, when to use it, and the meaning of each argument, including the delete edge case. The only omission is a return value, but the tool likely returns nothing, so this is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero description coverage, but the description compensates fully: category is exemplified with 'Output', name is scoped 'within that category', and value explains the None-to-delete semantics. This adds meaningful meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Write a raw parameter into the current profile's .ini configuration'—a specific verb, resource, and scope. It clearly distinguishes itself from sibling get_profile_parameter by being the write counterpart, and the 'advanced/low-level' tag further differentiates it from dedicated setter tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is provided: 'Advanced/low-level — prefer a dedicated request when one exists.' This tells the agent when to use this tool (as a fallback) and when to look for an alternative. It also implies the tool should not be used when a specialized setter is available.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool internally pulls three API endpoints, interprets specific ratios, and flags sustained issues heuristically rather than authoritative cutoffs. It also warns that a few skipped frames after start is normal, providing valuable behavioral context beyond what a schema could convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a one-sentence purpose, followed by a structured breakdown of the three key ratios and their meaning, plus concise fix suggestions. Every sentence contributes useful information, and the heuristic caveat at the end is relevant and concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's interpretive complexity, the description covers what the tool does, why it exists (to avoid manual arithmetic), how to interpret each ratio, practical fixes, and the heuristic nature of thresholds. There is no output schema, but the description provides the necessary interpretive context for the agent to act on the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the baseline is 4. There are no parameter semantics to elaborate, and the description appropriately focuses on the tool's interpretation logic instead of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a specific verb and resource: 'Diagnose why a stream/recording might be dropping frames or stuttering'. It clearly distinguishes itself from sibling raw-getter tools by stating it aggregates GetStats + GetStreamStatus + GetRecordStatus and interprets the ratios rather than just fetching data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly frames when to use the tool: when a stream/recording is dropping frames or stuttering, and contrasts it with the alternative of fetching three separate pieces of data and doing arithmetic. The included fixes for each scenario guide the agent toward next actions, and the heuristic caveat prevents over-triggering on normal noise.
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:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/xDarkzx/OBS_MCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server