OBS MCP

Server Quality Checklist

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

Latest release: v1.1.1
Disambiguation5/5
Each tool has a clearly distinct purpose with consistent verb-noun structure (get-, set-, create-, start-, stop-, toggle-, etc.) targeting specific OBS resources. Even similar tools like obs-get-input-audio-monitor-type vs obs-set-input-audio-monitor-type are unambiguously paired get/set operations. No two tools appear to do the same thing.
Naming Consistency5/5
The naming convention is extremely consistent: every tool starts with 'obs-' followed by a verb (get/set/create/remove/toggle/start/stop) and then a resource. This follows the OBS WebSocket API naming standards closely and is highly predictable.
Tool Count2/5
155 tools is excessive. OBS is complex but the tool surface was likely auto-generated from the full WebSocket API, including many low-level operations (e.g., set-input-deinterlace-mode, trigger-hotkey-by-key-sequence). This bulk will make it hard for an agent to find relevant tools.
Completeness5/5
The coverage is remarkably complete - scenes, sources, filters, media, outputs, transitions, profiles, hotkeys, studio mode, scene items (transform, enabled, locked, index, blend mode), persistent data, and even generic vendor/custom events. This appears to be a comprehensive mapping of the entire OBS WebSocket protocol.
Average 3.5/5 across 145 of 155 tools scored. Lowest: 2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 7 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under GPL 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.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations clearly mark this as read-only and idempotent, but the description adds no extra behavioral context such as error conditions, return format, or handling of invalid group names. Since the annotations already cover the safety profile, the description needed to explain the group semantics and it failed to do so.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is easy to read and directly to the point. However, its extreme brevity sacrifices essential details, which is a significant drawback despite being efficiently written.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is severely underspecified: there is no output schema, no required parameters, and no explanation of how to identify the group. The three optional scene-related parameters are ambiguous, and the agent receives zero guidance on correct invocation. This is completely inadequate for a tool that requires precise parameterization.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the schema has 100% coverage, the description adds no meaning beyond the parameter names and their short descriptions. Critically, there is no parameter for the group, and the description does not clarify how the group is identified via scene/canvas parameters. An agent cannot determine how to specify which OBS group to query, making the tool unusable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description restates the title almost verbatim, providing no additional clarity about the group identifier. It fails to distinguish this tool from the sibling obs-get-scene-items, and the missing group parameter makes the actual purpose confusing. A verb and resource are present, but the lack of group specification makes it vague and misleading.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool as opposed to alternatives like obs-get-scene-items, nor any prerequisites such as obtaining a group reference. The only hint is the tool's name itself, which is insufficient for correct invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. However, the description adds no behavioral context beyond that, such as what is returned if the input does not exist or whether the result is a key-value settings object, and there is no output schema to fill that gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and free of filler, but the single sentence repeats information already present in the title and parameter schema. It is terse rather than helpfully precise, so it is acceptable but not exemplary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and has rich annotations, but with no output schema and no mention that it retrieves current settings, the description is incomplete in this context. The ambiguity with obs-get-input-default-settings and the lack of return-value detail make it insufficient for confident selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully describes the only parameter: inputName is 'Name of the input to get the settings of'. Since schema description coverage is 100%, the description does not need to explain parameters, and the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Gets the settings of an input' is essentially a restatement of the title 'Get Input Settings' and the inputName parameter, adding no new scope such as 'current settings' or 'by name'. It also does not differentiate from the closely related sibling obs-get-input-default-settings, leaving ambiguity about whether this returns actual configured settings vs defaults.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like obs-get-input-default-settings or obs-set-input-settings. It has no exclusions, prerequisites, or context about when this tool is the appropriate 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?
Annotations already indicate this is a destructive, non-idempotent operation, but the description adds no extra behavioral context. It does not explain side effects, whether keys are pressed and released, how the hotkey sequence is processed, or what happens if the key does not exist. The description contributes almost nothing beyond the structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no wasted words, but it provides minimal informational value and largely repeats the tool name. It could use more detail about the key sequence format without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with a nested modifiers object and a clear alternative (trigger by name), a complete description should explain what counts as a sequence, how modifiers combine with keyId, and what side effects occur. The current one-line description is insufficient for an agent to use this tool safely and accurately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with keyId and keyModifiers both documented inline. The description adds no additional parameter meaning beyond the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says 'Triggers a hotkey using a sequence of keys,' which essentially restates the tool name and title without clarifying what 'key sequence' means or how it differs from the sibling obs-trigger-hotkey-by-name. It names the action and resource but fails to provide a specific, distinguishing definition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus obs-trigger-hotkey-by-name or other triggering tools. It does not mention prerequisites, limitations, or typical use cases, so an agent has no context for choosing it over alternatives.
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?
Annotations already declare readOnlyHint=false and idempotentHint=true, so the agent knows this is a state-changing but idempotent operation. The description adds nothing beyond the annotations; no mention of what happens to existing blend modes or if the operation is permanent, but since annotations cover the basic safety profile, this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is ultra-brief (one sentence) but fails to include essential usage context or parameter semantics. It is under-specified rather than concise; the description should have leveraged its brevity to add key guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 5 parameters (including sceneName, sceneUuid, canvasUuid) and no output schema, the description leaves the agent without guidance on which identification method is preferred, the impact of multiple scene identifiers, or the effect of invalid IDs. The description is not complete enough for a tool with this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema itself has high coverage (80%) for most parameters, but the sceneItemBlendMode enum values (e.g., OBS_BLEND_NORMAL) are not explained in the schema or description, leaving the agent without semantic guidance on which blend mode does what. The description does not compensate for this gap; thus, the score is below baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Set the blend mode of a scene item' is clear but spans only one line and does not differentiate from sibling tools like obs-get-scene-item-blend-mode or obs-set-scene-item-enabled. It is not a tautology, but it lacks specifics about the effect or scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention prerequisites such as the need to first retrieve the scene item ID. No context is provided for selecting a scene by name vs UUID.
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?
Annotations carry the behavioral disclosure: readOnlyHint=false, destructiveHint=false, idempotentHint=true, meaning the agent knows this is a non-read-only, non-destructive, retry-safe mutation. The description neither contradicts these annotations nor meaningfully extends them. It adds minimal value beyond what the structured hints already convey, so a neutral score is warranted with no contradiction flagged.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Eight words with zero waste, achieving maximum efficiency. However, the brevity reads more like a label than a description — every sentence earns its place, but the single sentence is doing so little work that it might as well not exist. It is appropriately sized but borderline under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a state-mutating tool with a nested filterSettings object, overlay semantics, and an optional canvasUuid, the total absence of context is a real gap. There is no mention of merge behavior beyond the schema's overlay parameter, no discussion of return values, and no cross-reference to related filter operations. The schema and annotations compensate substantially, but the description itself is nearly content-free for a tool with this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline of 3 applies per the rubric. All five parameters (sourceName, filterName, filterSettings, overlay, canvasUuid) have accurate descriptions in the schema, with "overlay" usefully clarifying merge-vs-reset behavior. The description itself contributes nothing to parameter understanding, but the schema fully compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
"Sets the settings of a source filter" uses a specific verb and resource and is technically accurate, conveying that the tool modifies filter configuration. However, it is nearly a verbatim restatement of the title and tool name, adding negligible disambiguation beyond the identifier itself. The word "settings" does subtly differentiate it from filter siblings like obs-set-source-filter-enabled or obs-set-source-filter-name, but this is implicit at best.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no when-to-use guidance, exclusions, or alternative tool references. With roughly a dozen filter-related siblings in the tool list (create, remove, get, set-name, set-enabled), the agent receives zero assistance in choosing among them. There is no explicit or even implied usage context distinguishing this mutator from its counterpart 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?
Annotations indicate readOnlyHint=false (it mutates state), idempotentHint=true (repeated calls are safe), and destructiveHint=false. The description simply says 'Switches to a scene collection' and does not elaborate on the behavioral implications, such as whether it changes the active collection globally, affects active scenes, or requires specific permissions. The description is consistent with the annotations but does not add extra context that annotations don't already imply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (a single sentence), so it is concise, but it is so minimal that it does not front-load any additional useful details. It could be considered under-specified rather than optimally concise, as it misses opportunities to add context without bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple with only one parameter and no output schema, so the description does not need to explain return values. However, given the lack of usage guidelines and behavioral transparency, the description is not complete for an agent to confidently use it. It could mention that the scene collection must already exist, or that switching may affect other scenes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema includes a description for the sole parameter, 'Name of the scene collection to switch to', which provides clear meaning. The description does not add anything beyond that, so the baseline of 3 applies because the schema already covers it perfectly (100% coverage).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb ('Switches to') and specifies the resource ('scene collection'), which is clear. It does not explicitly distinguish this from sibling tools like obs-create-scene-collection or obs-get-scene-collection-list, but the name itself is fairly distinctive.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as creating a scene collection or listing existing ones. It does not mention prerequisites, such as the collection needing to exist or being able to switch from the current one. 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?
Annotations indicate idempotentHint: true and destructiveHint: false, which are helpful. The description does not contradict annotations. However, it adds no details about side effects, such as whether settings are applied immediately, whether it can disrupt ongoing output, or whether certain settings require specific output types. Since annotations cover some safety aspects, the description adds marginal value but not complete transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence: 'Sets the settings of an output'. It is short and to the point, with no wasted words. However, it is extremely brief and lacks valuable context, which keeps it from a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is too minimal for a tool that modifies settings. It lacks context about what outputs are valid, how settings are structured, and any prerequisites or side effects. The annotations provide some safety info, but the description does not compensate for the lack of output schema and the complexity of the nested outputSettings object. It is below the minimum viable standard.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both parameters, but the descriptions are minimal: 'Output name' and 'Output settings'. The description's phrase 'sets the settings of an output' adds little beyond the schema. The nested object outputSettings is not explained in the description, but the schema already provides a definition. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool sets the settings of an output, which is a clear verb+resource. However, it does not differentiate from sibling tools like obs-get-output-settings or obs-set-output-settings (there is no obs-set-output-settings in siblings, but there is obs-get-output-settings), and the description is minimal. It is clear but lacks specificity about what 'output' refers to (e.g., streaming, recording, replay buffer).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It does not mention when it should be used instead of other output-related tools like obs-set-record-directory or obs-toggle-output. The description implies usage but does not provide any context for 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?
The annotations indicate destructiveHint=true and readOnlyHint=false, which the description does not contradict, but it also adds no additional behavioral details. It does not describe side effects, required permissions, or what happens when the request is called. The description relies entirely on annotations, which are 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no fluff. It is front-loaded with the action and resource, making it concise and efficient. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no output schema, a nested object parameter ('requestData') with unspecified structure, and no descriptions of valid request types, the description is incomplete. It does not explain what the requestData should contain, what the return value looks like, or any constraints. The description fails to fill gaps left by the schema and annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and all parameters have descriptions, but these descriptions are vague (e.g., 'appropriate request data'). The tool description does not add any additional meaning to the parameters. It simply repeats the action. Given the high schema coverage, the baseline score is 3, and no extra value is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Call a request registered to a vendor' clearly states the action (call) and the resource (request registered to a vendor). It distinguishes from the sibling tool 'obs-call-request' by specifying the vendor context. However, the term 'call' is somewhat ambiguous and could be more explicit about what the call does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like 'obs-call-request' or 'obs-describe-request'. The description does not mention any prerequisites, exclusions, or context where this tool is preferred. It simply states the action 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?
Annotations already indicate readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds nothing about runtime behavior (e.g., error conditions, return format), but since the bar is lower with annotations present, a 3 is appropriate for adding no 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, concise and front-loaded. It is not verbose, but it lacks detail. It is efficient, earning a 4.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema) and the annotations, the description is minimally adequate. However, it provides no context on expected outcome (e.g., range of balance values, meaning of return), which could be important for an agent. It is complete enough for a simple getter but could be improved.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameter is well-documented in the schema. The description adds no extra meaning beyond what the schema provides; baseline 3 is warranted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets the audio balance of an input, which identifies the verb and resource. However, it does not distinguish this from sibling tools like obs-set-input-audio-balance or obs-get-input-audio-sync-offset; the title already conveys the main purpose, so the description adds little beyond the 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/5
Does 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 prerequisites (e.g., that the input must exist) or when a user might need this over related tools. The description provides no context for selection.
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?
Annotations indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true, which already communicate that this is a safe read operation. The description adds no further behavioral context (e.g., what 'monitor type' values exist, if null is returned for non-audio inputs). Since the description is consistent with annotations and they already convey the key safe-read behavior, it gains no extra credit but doesn't need to.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
At 9 words, it is concise and front-loaded. There is no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity of the tool, a single descriptive sentence is arguably adequate. However, some additional context about potential return values or error conditions might help, but it is not strictly necessary. Overall, it does enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers 100% of the parameters with a clear description for 'inputName'. The description adds no additional input-specific context, but none is strongly needed. Baseline of 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Gets the audio monitor type of an input' uses a clear verb and resource, specifying it retrieves a setting for an audio input. It is not obviously a tautology, but it doesn't explicitly distinguish itself from sibling tools like 'obs-set-input-audio-monitor-type' beyond the get/set distinction, and doesn't elaborate on what an 'audio monitor type' is. It is clear for an expert familiar with OBS, but lacks context for a general agent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, such as when to use the setter or how this relates to other input audio queries like mute or volume. The description implies it is for retrieving a setting, but with no context on prerequisites or typical use cases, it does not help an agent decide when this tool is the right choice over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this as read-only and idempotent. The description adds the phrase 'asynchronous input,' which is confusing and potentially misleading since inputs are not typically described as asynchronous. It fails to clarify what happens if the field order is not set, if the input doesn't exist, or what default value is returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no fluff. It loses a point because the word 'asynchronous' is an unhelpful qualifier that introduces confusion rather than clarifying behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless-required getter with no output schema, the description does the bare minimum. The zero-required-parameters setup combined with no elaboration on identifier precedence or default field order values is a notable omission that could frustrate an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% since both parameters have simple, self-descriptive descriptions ('Name of the input' and 'UUID of the input'). The description provides no additional detail about parameter interplay, such as whether both can be omitted or if one takes precedence.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb and resource: get the deinterlace field order of an input. It distinguishes itself from the sibling obs-set-input-deinterlace-field-order through the 'get' semantics, and the title precisely matches the function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor any prerequisites such as the input needing to be an interlaced video source. It doesn't mention that one of the two optional parameters should likely be provided, leaving an agent without any direction on invocation 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?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the tool's safe read-only nature is known. However, the description adds no behavioral context beyond repeating the tool's name, such as what status values are returned, whether it reflects live state, or any prerequisites. No contradiction with annotations exists, but there is no added transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no wasted words. It is easily scannable and front-loaded, though it could be slightly more informative without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema, the description does not explain what information is returned or what 'status' means in OBS context (e.g., playing, paused, stopped). Given the presence of many media-related sibling tools, the description is too minimal to fully guide an agent on expected behavior and return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with a clear description for the single required parameter inputName. The description adds no extra semantic detail beyond 'Name of the media input,' so it meets the baseline but does not enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Gets') and resource ('status of a media input'), making it easy to understand the tool's basic function. It is distinct enough from sibling getters like obs-get-input-settings or obs-get-input-mute by targeting 'media input status' specifically, though the exact meaning of 'status' remains vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternative getters. The description does not mention any specific use cases, exclusions, or relationships to sibling tools such as obs-get-input-settings or obs-set-media-input-cursor. Usage is only implied by the name, not explicitly explained.
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 adds no behavioral traits beyond what the annotations already declare (readOnlyHint=true, idempotentHint=true, destructiveHint=false). It does not describe what kind of status is returned, possible states, or any caveats, nor does it add context like date-range scoping as seen in the calibration example.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler words, making it appropriately concise for a trivial getter. It is front-loaded and easy to parse, though it sacrifices informative content for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (one parameter, no output schema, simple read-only getter), the description is minimally viable but incomplete. It does not specify what output status values look like or how to obtain valid outputName values, though the sibling tool obs-get-output-list could fill that gap. More context about the return format would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% because the single parameter outputName has the description 'Output name'. The tool description adds no extra parameter meaning, so the baseline of 3 applies; the schema alone carries the semantic weight.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
"Gets the status of an output" clearly identifies the action (get) and resource (output status), matching the title and distinguishing it from sibling tools that get output settings or lists. It is concise and unambiguous, though it does not explicitly contrast with related status tools like obs-get-record-status or obs-get-stream-status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. No context, exclusions, or references to related tools (e.g., obs-get-output-list for retrieving valid output names) are provided, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds no extra behavioral context beyond a restatement of the action. It does not mention potential errors, return format (e.g., integer index), or any edge cases, so it adds minimal value over annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no fluff. It is front-loaded with the verb and object. However, it is slightly under-specified—it could mention that it returns an integer or that it requires a scene item ID—but it remains efficient and does not waste words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple getter with four parameters and no output schema. The description does not explicitly state the return value (integer index) or describe what happens if the scene item is not found. Given the annotations and schema detail, it is adequate but leaves gaps that could confuse an agent expecting richer context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and each parameter already has a descriptive comment. The description adds no extra meaning beyond what the schema provides, so the baseline score of 3 is appropriate. There is no additional clarification about parameter relationships or usage patterns.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Get the index position of a scene item'. It uses a specific verb and resource, making it distinct from sibling tools like obs-get-scene-item-id (which retrieves ID) and obs-set-scene-item-index (which sets index). However, it does not explicitly differentiate itself from these siblings, so it doesn't earn a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any context like ordering, zero-based indices, or why one might need the index. No exclusions or alternative tool suggestions are given, leaving the agent without direction for 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?
Annotations (readOnlyHint=true, idempotentHint=true, destructiveHint=false) fully cover the safety profile, and 'Gets the info' is consistent with these—no contradiction. However, the description adds essentially nothing beyond the annotations: no clarification of what 'info' contains, no mention of the optional canvasUuid disambiguation behavior, and no error/edge-case notes. The HIGH example received a 3 for adding date-range scoping context; this description has no equivalent added 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, grammatically correct sentence that front-loads the key information with no wasted words—'Gets the info for a specific source filter' earns every word. It's appropriately sized for a simple getter. Slightly docked because the word 'info' is vague (versus 'settings' or 'configuration'), but this is a marginal quibble for an effectively concise description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only operation with no output schema and 100% parameter coverage, this description is functional but minimal. It meets the 'minimum viable' bar: an agent could correctly reason this returns data for a single filter. However, since there's no output schema, the description's job is larger, and it could have clarified what 'info' means (e.g., settings, enabled state) or that the source name can be disambiguated by an optional canvas UUID—context that would materially help the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline of 3 applies even though the destination description provides no parameter details. The schema fully documents sourceName and filterName, and the optional canvasUuid is self-describing. The description adds no parameter-level information, but the rubric doesn't require it at this coverage level.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Gets the info for a specific source filter' uses a specific action verb ('Gets') and resource ('source filter'). The word 'specific' subtly distinguishes it from the sibling list variant (obs-get-source-filter-list), but unlike the highest-caliber examples, it doesn't explicitly name the alternative tool or contrast itself against related getters like obs-get-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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no when-to-use guidance, exclusions, or mention of alternatives. Unlike the HIGH calibration example that explicitly suggested 'use search_calls_extensive instead', this description doesn't help the agent decide between this and the closely related obs-get-source-filter-list, obs-set-source-filter-settings, or others. The guidance is simply absent, not misleading.
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 adds no behavioral context beyond the annotations. It doesn't state whether multiple projectors can be opened, whether it opens a new window each time, or what happens if the source is deleted. The idempotentHint=true is present but not corroborated or explained. Given the lack of added detail, this dimension is weak.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no redundancy. It is appropriately concise, though it could be slightly more informative without becoming verbose. The structure is front-loaded with the verb, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 5 parameters and no output schema, the description is insufficiently complete. It doesn't mention how the projector behaves (windowed vs fullscreen), how monitorIndex works (though schema does), or any side effects. An agent would struggle to understand the full implications of calling this tool. This is a significant gap for a tool with multiple optional parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with all five parameters described (canvasUuid, sourceName, sourceUuid, monitorIndex, projectorGeometry). The tool description itself adds no parameter-level detail, so the baseline of 3 is appropriate since the schema carries the semantic load.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action ('opens') and object ('projector') with a target ('for a source'), which is clear and distinguishable from the sibling tool 'obs-open-video-mix-projector' that targets video mix. However, it does not elaborate on what a projector is or what 'open' implies (e.g., separate window or monitor), leaving some ambiguity for users unfamiliar with OBS terminology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like 'obs-open-video-mix-projector' or how it fits into a workflow. The description doesn't mention prerequisites (e.g., source must exist) or typical use cases, so an agent would not know when to invoke it over similar 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?
The annotations already declare destructiveHint=true and readOnlyHint=false, indicating a write operation with potential side effects. The description adds nothing beyond the literal action of pressing a button; it does not disclose potential consequences, reversibility, or any effects on the input's state. No value added beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler. It is concise and front-loaded, stating the core action immediately. 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/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal and fails to provide sufficient context for a destructive operation. It does not clarify how to identify the input (inputName vs inputUuid), mention that this could trigger side effects, or explain any prerequisites. Given the absence of an output schema and the destructive annotation, more context is needed to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with each parameter having a description. The tool description does not add any additional meaning, such as the relationship between inputName and inputUuid (e.g., that at least one should be provided) or what propertyName refers to. Since the schema already documents the parameters, baseline 3 applies, and no extra context is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool presses a button exposed by an input property. The verb 'press' is specific and the resource is defined as a button on an input property, which distinguishes it from other input-related tools like obs-set-input-settings or obs-trigger-media-input-action. However, it could be more explicit about what an 'input property' is, so not a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. It does not mention whether this is for interactive buttons that open dialogs or trigger actions, nor does it suggest when not to use it. No alternatives are referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate 'destructiveHint: true', which suggests this tool can modify state or create files, but the description only says 'saves' without clarifying side effects (e.g., overwriting existing files, required permissions, or impact on sources). The description does not add significant context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that is front-loaded with the action. It is concise and efficient, though it misses additional context that could be useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 8 parameters with 100% schema coverage and no output schema, the description is somewhat minimal. It covers the basic purpose but lacks details such as how the screenshot is saved, interactions with the filesystem, or performance considerations. However, for a straightforward save operation, it may be sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the description adds no extra meaning beyond what the schema already provides. However, the description mentions 'screenshot of a source' which aligns with the parameters, but it doesn't explain parameter constraints like imageCompressionQuality semantics beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Saves a screenshot of a source') and the destination ('to the filesystem'), which is specific enough. It distinguishes from the sibling tool 'obs-get-source-screenshot' by mentioning the saving aspect, though it could be more explicit about the difference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives, such as when to use 'obs-get-source-screenshot' instead. The description doesn't specify any prerequisites or context for using it.
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 adds no behavioral context beyond what the annotations already declare (readOnlyHint false, destructiveHint false, idempotentHint true). It does not mention that changing the offset affects audio timing, persistence, or any side effects. Since annotations cover the safety profile, the description still fails to add meaningful transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is appropriately concise for a simple setter. It is front-loaded with the action, but could have included more details while still being efficient. No wasted words, but it is minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool, the description is still insufficient for complete guidance. It does not explain what the offset does (e.g., adjusts audio-video synchronization), when it should be applied, or any consequences. With no output schema and minimal annotations, the description leaves the agent inferring behavior from the name alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and both parameters have clear descriptions in the schema. The tool description does not mention parameters at all, so it adds no additional meaning beyond the structured schema. Baseline of 3 is appropriate because the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Sets the audio sync offset of an input'. It is specific about the verb and resource, and it distinguishes from the sibling getter tool (obs-get-input-audio-sync-offset). However, it lacks any nuance about scope or constraints beyond the parameters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, prerequisites (e.g., input must exist), or scenarios where this tool is appropriate. The sibling list includes many setter tools, but no differentiation is given.
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 readOnlyHint=false and destructiveHint=false, the description's 'sets' is consistent but adds nothing. It fails to mention that this operation may replace or merge settings (overlay parameter), or that it's idempotent (already indicated by annotations). No additional behavioral context is provided beyond what annotations and schema already reveal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence with no fluff, making it extremely concise. However, it might be under-specified for a tool with a nested object and overlay semantics, but from a purely structural standpoint, it is efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with a nested inputSettings object and no output schema, the description provides minimal context. It doesn't clarify that inputSettings is an arbitrary property map, how overlay controls merge vs. reset, or what happens on failure. The schema describes overlay, but the description doesn't compensate for the missing operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters are fully described in the schema (100% coverage), so the baseline is 3. The description adds no additional parameter information, but the schema already explains the overlay flag and the inputName/inputSettings meaning. The description's lack of param details is acceptable given schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Sets the settings of an input' uses a clear verb-resource pair and makes the core function immediately obvious. It does not differentiate from sibling set-* tools like obs-set-input-audio-tracks or obs-set-input-volume, but the generic 'input settings' is distinct enough for basic identification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool instead of the many specialized setter tools for input audio, mute, volume, etc., nor does it mention prerequisites or typical use cases. The only context is what can be inferred 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?
The description adds negligible behavioral context beyond the annotations. The annotations already indicate it's not read-only, not destructive, and idempotent. The description merely restates the mutation intent without disclosing side effects (e.g., reordering implications, impact on other scene items, or error conditions). With annotations covering the safety profile, the low added value warrants a 2.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence that directly conveys the core function with zero superfluous words. It's front-loaded and perfectly concise for a straightforward setter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has five parameters, including multiple optional ways to identify the scene (sceneName, sceneUuid, canvasUuid), yet the description doesn't explain how to choose among them or whether one is preferred. It also doesn't clarify what 'index' means in terms of ordering (likely z-order) or the effect of setting an out-of-range index. Given the ambiguity in scene identification and index semantics, the description is incomplete for a reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All five parameters are described in the schema (100% coverage), so the baseline is 3. The description does not add any semantic meaning beyond what the schema already provides—it simply names the action. The 'sceneItemIndex' parameter is defined as 'New scene item index' in the schema, and the description doesn't clarify index semantics (e.g., if it's 0-based or relational). Since there's no additional value, a 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action: setting the index position of a scene item. It distinguishes from sibling tools like obs-get-scene-item-index (which retrieves the index) and obs-set-scene-item-enabled (which toggles enabled state) by specifying the verb 'set' and the resource 'index position'. However, it doesn't explain what 'index' means (e.g., z-order or render order), so it's not fully explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, when to prefer this over obs-set-scene-item-transform or other scene item modifiers, or any exclusions. The usage context is implied but never 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?
Annotations already indicate idempotency and non-destructiveness, but the description adds no behavioral context beyond that. It doesn't disclose that settings will be completely replaced, whether certain settings are required, or any impact on current settings. With annotations present, the bar is lower, but the description still fails to add meaningful transparency about the operation's effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no redundant wording. It front-loads the action and resource. However, it is extremely minimal—almost terse—which, while efficient, leaves out potentially useful context. It earns a 4 for brevity but not a 5 because it sacrifices helpfulness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a set operation that affects stream service settings, the description is too thin. It doesn't explain that it overwrites existing settings, nor does it provide any usage context like when to call this versus obs-get-stream-service-settings. With no output schema and nested objects, the description should offer more to make the tool fully contextual.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage of both parameters with descriptions and an example for streamServiceType. The tool description adds no additional parameter information, so it doesn't go beyond the schema. Baseline 3 is appropriate since the schema already documents the parameters well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Sets the current stream service settings' clearly identifies the action (set) and the resource (stream service settings). It distinguishes from the sibling obs-get-stream-service-settings by the verb, but doesn't explicitly mention that distinction. It could be more specific about the scope (e.g., current vs. specific service), but it's clear enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention the complementary get operation or any prerequisites. The context signals show a sibling for getting settings, but the description says nothing to help the agent decide when to invoke 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?
Annotations already convey readOnlyHint=false, destructiveHint=false, and idempotentHint=true, so the safety profile is clear. However, the description adds no additional behavioral context—it does not explain what happens on a partial update, whether all parameters must be provided or can be omitted, or any side effects. Since annotations cover the basic safety traits but the description contributes nothing beyond that, a 2 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler or redundant information. It is extremely concise and front-loaded, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With six optional parameters and no output schema, the description is too sparse to be complete. It does not clarify whether all settings are required, what happens if only some are provided, or what 'current video settings' entails. The tool complexity demands more guidance than this one-liner provides.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so every parameter has a description in the schema itself. The description text adds no parameter-level information beyond the schema. Per the rubric, baseline is 3 when schema covers all parameters, so this is adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (sets) and the resource (current video settings). It is distinguishable from sibling getter tools like obs-get-video-settings, though it does not enumerate exactly which settings are affected. This is sufficient for a basic purpose but lacks specificity about the actual settings (resolution, FPS).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, when it is appropriate to invoke, or that there is a getter sibling for reading current settings. The description 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?
Annotations already indicate that this is a mutating operation (readOnlyHint: false), not idempotent, and not destructive. The description adds no behavioral context, such as what happens if the output is already started, prerequisites, or error handling. For a mutation tool, the description should clarify side effects, but it remains silent, leaving the annotations to carry the full burden without any added value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with zero wasted words. It is appropriately concise for a straightforward action, and the message is front-loaded. No redundancy or padding exists.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a mutating operation with a single required parameter and no output schema, the description is overly sparse. It fails to convey what starting an output entails—whether the output must exist, if it can be restarted, or if any state changes are expected. The sibling tools suggest a broader output management context, but this description alone is insufficient for an agent to confidently execute the action without additional assumptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema includes a single parameter 'outputName' with a basic description ('Output name'). Since schema coverage is 100%, the baseline is 3. The tool description adds no additional meaning or constraints for the parameter, such as valid formats, required precision, or examples. It simply repeats the parameter's purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Starts an output' clearly conveys a specific action (start) on a resource (output). It is unambiguous and the verb-resource pairing is clear. However, it does not explicitly differentiate from the sibling tool that toggles outputs (obs-toggle-output), which could also start an output if it is not running. The name hints at the distinction, but the description itself doesn't mention when to use start over toggle.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit or implicit guidance on when to use this tool versus alternatives like obs-toggle-output or obs-stop-output. The description only states the action, leaving the agent to infer context. Sibling tools provide related functionality, but no usage direction is given.
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 annotations already convey readOnlyHint=false and idempotentHint=false, and the description only restates 'toggles' without adding behavioral context such as what 'status' means, what side effects occur, or whether it toggles between specific states. It adds minimal value beyond the structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence with no wasted words, making it very concise. It is front-loaded with the action verb, but the brevity also contributes to vagueness about what 'status' entails.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description is minimally adequate. However, it fails to clarify what 'toggling status' means in practice, and the presence of sibling start/stop/get-status tools suggests more context would help an agent invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single outputName parameter, so the schema fully documents it. The description does not add any additional meaning about the parameter's format, constraints, or relationship to the tool's behavior, matching the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Toggles' and identifies the resource as 'the status of an output', clearly distinguishing it from toggles for other entities like record, stream, or virtual cam. However, 'status' is vague and does not specify what state changes (e.g., started/stopped), leaving slight ambiguity even with sibling context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given for when to use this tool versus alternatives like obs-start-output, obs-stop-output, or obs-get-output-status. With many sibling toggle tools, the description provides no exclusions or context for 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?
Annotations indicate no readOnly, so it mutates media input state, but the description doesn't add behavioral context like potential side effects (e.g., stopping playback) or irreversible actions. No output schema, so no return details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, concise sentence, but under-specified for a tool with multiple actions. It is appropriately short, not verbose, but lacks useful detail the sentence could add.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is no output schema and limited annotations, the description should explain behavior or side effects but does not. The tool is straightforward but could benefit from clarifying that actions map directly to OBS media controls.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already describes both parameters with clear names and enums; description adds minimal value beyond restating the action enum. Since schema coverage is 100%, baseline is 3, but no additional format or context is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it triggers an action on a media input, with specific verbs and resource. It distinguishes itself from media status/cursor tools but could be more specific about what actions entail.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, such as when to use pause/play vs stop/restart. The sibling tools include get-media-input-status, but no mention of checking status before actions or any 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?
Annotations indicate idempotentHint=true and destructiveHint=false, which are consistent with the description. However, the description does not add any behavioral details beyond the annotations, such as what happens if the output is already stopped or if the output name is invalid. It does not mention side effects or error conditions, but given that annotations already cover safety, this is 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no fluff. It is appropriately sized for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple tool with one parameter and good annotations, but the description is sparse. It could benefit from a note clarifying what 'output' means in OBS (e.g., streaming, recording, virtual cam) and that it complements obs-start-output and obs-toggle-output. The lack of output schema reduces the need for return details, but some context on preconditions would help.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage for the single parameter (outputName described as 'Output name'). The description 'Stops an output' does not add meaning beyond the schema; it doesn't explain what an 'output' refers to or what valid names look like. However, since the schema fully describes the parameter, the baseline score is 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Stops an output' is clear but minimal. It specifies the verb 'stops' and the resource 'output', but it does nothing to distinguish from sibling functions like obs-stop-record, obs-stop-stream, or obs-stop-virtual-cam, which also stop some kind of output.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. The description does not mention that it requires an output name or clarify that it applies to a specific type of output (e.g., streaming, recording, virtual cam). It fails to explain how it relates to obs-toggle-output or obs-start-output.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description does not add behavioral context beyond confirming a read operation; it omits details like return format, error conditions, or side effects. Since it adds no extra value over annotations, the score is low.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear, and front-loaded sentence with no wasted words. It efficiently communicates the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter getter with read-only and idempotent annotations, the description is adequate but does not explain what 'default settings' entails or what the response contains. Given the absence of an output schema, a bit more detail would help, but the simplicity keeps it at an acceptable level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully describes the only parameter (filterKind) with 100% coverage. The description does not add parameter-specific information beyond the general purpose, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to get default settings for a filter kind. It uses a specific verb ('Gets') and resource ('default settings for a filter kind'), distinguishing it from input-related siblings by specifying 'filter kind'. However, it doesn't explicitly differentiate from similar tools like obs-get-input-default-settings, so a slight deduction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention prerequisites or related tools. It only states the action without any contextual usage hints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the call read-only, idempotent, and non-destructive, but the description adds no behavioral context beyond that—for example, what the returned list contains, whether it respects a scene collection/canvas scope, or how omitted canvasUuid behaves. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It is concise and immediately scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one well-described optional parameter, this is minimally usable, but there are gaps: no output schema means the agent is not told the shape or contents of the returned scene list, and the optional canvas parameter's omission semantics are not explained. Sibling differentiation is also absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single canvasUuid parameter has a clear inline description, so the schema carries the meaning. The tool description itself does not discuss parameters, but no compensation is needed; however it also does not add extra nuance about required/optional behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource ('Get a list of scenes'), so the core purpose is clear. It does not distinguish itself from sibling tools such as obs-get-scene-items or obs-get-current-scene, nor does it mention the canvas-scoped behavior implied by the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use or when-not-to-use guidance is provided; the description only restates the operation. The sibling tool list contains related scene methods (obs-get-scene-items, obs-get-current-scene, obs-set-current-scene), and this description gives the agent no criteria for choosing this one over them.
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?
Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which establish a safe, non-destructive read operation. The description adds no further behavioral context beyond stating it retrieves names, which is implied by 'Gets'. No contradiction. It doesn't mention any caveats like empty lists or special cases, but with strong annotations, this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded and free of waste. It could be slightly more informative about what 'special inputs' encompasses, but it is appropriately brief.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, no output schema, and strong annotations, the description is minimally sufficient. However, given the extensive sibling list, it would be more complete if it clarified the scope of 'special inputs' (e.g., which kinds of sources qualify), but that is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the description need not clarify parameters. The baseline for zero-parameter tools is 4, and the description confirms the tool's purpose (getting names) without requiring parameter explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Gets the names of all special inputs' is a clear verb+resource statement, but it doesn't specify what 'special inputs' means or how it relates to the many sibling tools. The title adds nothing. The description is adequate but lacks explicit differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no context on when to use this tool versus alternatives like 'obs-get-input-list' or 'obs-get-input-kind-list'. It doesn't explain the use case for special inputs, so an agent would have to guess.
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 adds minimal behavioral insight beyond what annotations convey. It states the action but does not disclose side effects such as whether the dialog is modal, blocks execution, or requires user interaction. The idempotentHint=true annotation is helpful but not expanded upon; the description lacks details on what happens when the dialog is opened (e.g., if it auto-closes or remains).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no redundant information. It efficiently conveys the core functionality without any fluff or unnecessary qualifiers.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and has no output schema, but the description lacks any mention of the expected behavior or return value. It doesn't state whether the tool returns a status code or success indicator, or if any side effects occur beyond opening the dialog. Given the simplicity, a score of 3 is reasonable, but it could be more complete by noting that it is an asynchronous UI operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides descriptions for both parameters ('Name of the input' and 'UUID of the input'), so the description adds little extra meaning. It does not clarify whether the parameters are mutually exclusive, if one takes precedence, or if both are required. The coverage is high, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Opens the properties dialog') and the resource ('of an input'), which is specific enough to differentiate from other input-related operations like getting or setting settings. It could be more explicit about distinguishing from similar tools like 'obs-get-input-settings', but it serves its purpose well.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention, for example, that this is for interactive UI, while other methods are for programmatic access. There is no context on prerequisites or conditions that would make this the preferred choice.
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?
Annotations indicate readOnlyHint=false, destructiveHint=false, idempotentHint=true. The description adds minimal context beyond annotations — it says it sets a value, implying a write operation, but doesn't disclose side effects, permissions, or any special behaviors. However, the descriptions aligns with annotations, so no contradiction. The bar is lower due to annotations, but the description still doesn't add much 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, concise and front-loaded with the verb. It is suitably sized for a simple slot-setting operation. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has 3 simple parameters, full schema coverage, and no output schema, the description is minimally adequate. However, it lacks any note on how the 'persistent data realm' works, or any caveats. For a simple setter, this might be sufficient, but it could be improved by explaining what the slot is used for.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds little beyond the schema, but it does relate 'the value of a slot' to the slotName and slotValue parameters, providing slight context. However, it doesn't clarify the meaning of 'realm' beyond the schema's enum-like description. Overall, the description adds marginal value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'Sets' and the resource 'slot' from 'persistent data realm', but it is vague about what the slot represents or what 'persistent data' is. It partially distinguishes from the sibling tool 'obs-get-persistent-data' (which gets data instead of sets), but could be clearer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. It might be obvious that 'obs-get-persistent-data' retrieves data while this sets it, but the description provides no explicit context for usage, prerequisites, 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?
Annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=true. The description adds the semantics of 'show' vs 'hide' based on the boolean, which is helpful but minimal. It does not add context about side effects or behavior beyond what annotations cover, so 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (5 words) with no fluff. It is front-loaded and gets straight to the point. However, it might be too terse, lacking useful context, but for a simple setter tool, it is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool complexity is low, but there are 5 parameters and no output schema. The description does not clarify which scene identifier is required, potential errors, or the return value (likely empty). It also doesn't mention that the operation is idempotent (though annotation covers that). Given the need to know how to specify the item, the description is incomplete for safe usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are self-explanatory. The description does not add any parameter-specific information beyond what the schema provides. However, it does imply the meaning of 'enabled' but doesn't clarify the optional nature of sceneName vs sceneUuid. Baseline 3 is appropriate given high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Show or hide a scene item' clearly states the action (show/hide) and the resource (scene item). It distinguishes the tool's purpose from siblings like obs-get-scene-item-enabled (which reads visibility) and obs-set-scene-item-transform (which sets transform). However, it does not explicitly mention that it applies to a specific scene item identified by ID, though that is implied.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives or any prerequisites. It does not mention that the scene item must exist or that sceneName/UUID is required (though schema shows them optional, but likely one is needed). 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not add any behavioral details beyond the annotations. It does not mention whether creating a scene with an existing name fails, whether it affects the current scene, or any other side effects. The annotations only indicate non-read-only and non-destructive, but the tool's actual behavior remains opaque. The description contributes nothing to transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with exactly one sentence. It conveys the essential purpose without any fluff or unnecessary detail. It is well-structured for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is too minimal to be complete for a create operation. It does not mention any return value, error conditions, or impact on the scene collection. Since there is no output schema, the description should ideally provide some context about what happens after creation, but it does not. This leaves the agent and users with significant gaps in understanding the full behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for both parameters (sceneName and canvasUuid), so schema coverage is 100%. The tool description does not add any additional meaning or clarify the relationship between the parameters. Since the description itself adds no value beyond the schema, it stays at the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Create a new scene in OBS'. It specifies the verb (create) and the resource (scene), and it is distinct from other scene-related operations like get, set, or remove. 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any prerequisites, side effects, or scenarios where it is appropriate. For example, it does not differentiate from creating a scene item or switching scenes. The one-line description offers 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?
Annotations already indicate readOnlyHint=false, so the mutation is known. The description adds no behavioral context such as duplicate behavior, error conditions, or what happens if identifiers are invalid, making it minimally informative beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It efficiently states the action and target resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With six optional parameters and no output schema, the description should clarify identifier alternatives (sceneName vs sceneUuid, sourceName vs sourceUuid) and what the tool returns. It provides none of this context, making it incomplete for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all six parameters are already documented in the input schema. The description adds no additional parameter semantics, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb ('Create') and clearly identifies the resource ('scene item') and context ('for a source in a scene'). This distinguishes it from sibling tools like obs-remove-scene-item and obs-duplicate-scene-item.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor are prerequisites mentioned such as the source and scene needing to exist. The usage context 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?
The annotations (readOnlyHint=true, idempotentHint=true, destructiveHint=false) already establish this as a safe read operation. The description's 'Get' is consistent with these annotations but adds zero behavioral insight beyond what annotations convey—no error handling, auth requirements, or value formats mentioned. No contradiction with annotations found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One clean, front-loaded sentence with zero filler. It's an appropriately sized description for a simple getter. It loses a point because it misses the opportunity to add a useful note (like referencing the setter) that would elevate it from adequate to genuinely helpful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only getter with strong annotations and complete schema coverage, this description is nearly adequate. However, with no output schema present, the description could have clarified the return value format (e.g., what blend mode values to expect). It's a minimum-viable description—complete but unremarkable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with all four parameters (sceneName, sceneUuid, canvasUuid, sceneItemId) already documented in the schema. Per the rubric's baseline, this earns a 3. The description contributes nothing about parameters, but the schema fully handles it, so no deduction is warranted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get the blend mode of a scene item' uses a specific verb+resource pattern and clearly states what it retrieves. It's clear but doesn't make any effort to distinguish itself from sibling getters (e.g., obs-get-scene-item-transform), which per the rubric maps to a 4.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description doesn't mention when to use this tool versus alternatives, doesn't reference the setter counterpart (obs-set-scene-item-blend-mode), and gives no context about prerequisites like needing a scene item ID first. This matches 'no guidance' at score 2.
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?
Annotations declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds the specific 'active and show state' context, but doesn't explain what 'active' means (e.g., visible in a scene) or whether the show state refers to a canvas or scene. It doesn't contradict annotations, but adds minimal value beyond the annotation-provided 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, concise and to the point. It front-loads the purpose without rambling. However, it could have been slightly more informative about the 'show' state, but overall it is efficient and earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is no output schema and only a terse description, the agent might not know what the response includes (e.g., a boolean flag for active, a show state). With 3 parameters and zero required, it's ambiguous how the tool behaves without specifying any parameters. A richer description would clarify return values and parameter optionality, but the annotations help somewhat.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all three parameters (canvasUuid, sourceName, sourceUuid) are documented in the schema. The description itself doesn't clarify the relationship between canvasUuid and sourceUuid, or whether sourceName is required, but the schema's own descriptions adequately convey parameter meaning. No additional semantics are provided beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Gets the active and show state of a source' clearly states the verb (gets) and the resource (source), and specifies the two aspects being retrieved: active and show state. It distinguishes from siblings like obs-get-input-list or obs-get-scene-items by focusing on the active state of a source, though it doesn't explicitly differentiate from other 'get' tools in the sibling 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention scenarios where a source is part of a scene or canvas, or whether there are other tools for retrieving source state (e.g., obs-get-scene-item-enabled). The context of needing canvasUuid or sourceUuid is implied but not clarified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate idempotentHint=true, so the tool is safe to call multiple times without side effects. However, the description doesn't add context beyond this, such as whether the tool has any effect when studio mode is off, or whether it requires specific permissions. No annotations contradiction, but the description could add more 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise—one sentence with no wasted words. It front-loads the action and resource clearly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with 100% schema coverage and idempotentHint, the description is adequate but doesn't explain return values or side effects. It's complete enough for a straightforward setter, but could benefit from mentioning studio mode requirement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the parameter 'sceneName' is sufficiently described in the schema ('The name of the scene to set as preview'). The description adds minimal value beyond the schema, but since coverage is high, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (set) and the target resource (preview scene) in OBS Studio Mode. It distinguishes itself from related tools like obs-set-current-scene and obs-trigger-studio-transition by specifying 'preview' scene, though it doesn't explicitly contrast with siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage in 'OBS Studio Mode' but doesn't explain when to use this instead of obs-set-current-scene or when preview mode must be enabled. It doesn't mention prerequisites like studio mode being active, 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?
The description adds the scope of mutation (position, rotation, scale, or crop), which the annotations do not state, and it is consistent with idempotentHint and destructiveHint. However, it does not disclose meaningful behavioral details such as partial-update semantics, units/coordinate conventions, or how sceneItemTransform interacts with the scalar fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant wording. It is appropriately brief, though it sacrifices some behavioral and usage context for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The schema covers all parameter meanings and the annotations cover basic safety traits, making the tool usable, but the description is minimal for a 14-parameter setter with no output schema. It lacks guidance on partial updates, unit conventions, and the relationship between sceneItemTransform and individual transform fields.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 14 parameters already have descriptions in the schema, providing 100% coverage, so the baseline is 3. The description merely summarizes the same properties and does not add any new meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('set') and identifies the resource ('scene item') plus the concrete properties affected (position, rotation, scale, crop), which clearly distinguishes it from scene-item getters and other scene-item setters. It stops short of a 5 because it does not explicitly name related alternatives like obs-get-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 Guidelines2/5
Does 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 sibling tools, such as obs-get-scene-item-transform or other scene-item setters. The intended use is only implied by the title and description, with no exclusions or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a non-read-only, non-idempotent action, and the description adds no additional behavioral context such as side effects, error behavior, or whether the buffer is reset. It does not contradict the annotations, but it also provides no value beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler words. It states the action economically and earns its place even though it is minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, no-parameter mutating command, the description is minimally viable. However, it lacks useful context about replay buffer output semantics, prerequisite state, or how this relates to sibling commands like save and toggle, making it 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/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero properties, so schema coverage is effectively 100% and there are no parameters for the description to explain. The 0-parameter baseline applies, and no additional parameter documentation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Starts' and identifies the 'replay buffer' resource, making the primary action clear. It broadly distinguishes from stop/toggle/save siblings, though it does not explicitly explain the relationship to obs-toggle-replay-buffer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool instead of obs-toggle-replay-buffer, what state prerequisites exist, or what happens if the replay buffer is already active. The description only states the action without any context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations are all false and uninformative, leaving the description to carry the behavioral burden. 'Toggles the status of the record output' adds little beyond the tool name and does not explain side effects, state transitions, or edge cases (e.g., what happens if recording is in a transitional state). More transparency about the toggle behavior would be 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no unnecessary words. It perfectly communicates the core action in the most economical way possible.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, parameterless toggle operation, the description covers the essential action. However, it does not mention return values (e.g., whether it returns the new state) or error conditions. Given the low complexity, this is acceptable but not outstanding—more context about the toggle's effect on the recording state would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, the schema provides complete coverage by definition. The description does not need to explain parameter semantics, and the baseline of 4 is appropriate since there is nothing to add. No further clarification is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the verb 'toggles' and the resource 'record output', which distinguishes it from sibling tools like obs-start-record and obs-stop-record. However, 'record output' is slightly ambiguous without OBS context and could be interpreted as an audio output rather than the recording state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like start-record, stop-record, or toggle-record-pause. The description does not mention that this is a convenient way to toggle the recording state without checking current status, nor does it advise when to prefer start/stop instead.
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 annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, fully covering the safety profile of this getter. The description adds the 'active' scope qualifier but reveals nothing beyond that—no mention of response shape or studio-mode behavior. It is consistent with annotations, just not additive 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence, front-loaded with the key action, with zero wasted words. However, it essentially restates the title verbatim, adding no new information—concise but minimal to the point of being almost purely a paraphrase.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only getter with rich annotations (readOnly, idempotent, non-destructive) and no output schema, the description is mostly adequate. However, given the sibling obs-get-preview-scene, clarifying that 'active' refers to the program scene (especially relevant in studio mode) would materially improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is 100% (empty schema). There is nothing for the description to explain, so the baseline of 4 applies. No parameter documentation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get') and resource ('current active scene in OBS'). The word 'active' helps differentiate it from the sibling obs-get-preview-scene, though it does not explicitly name or distinguish itself from sibling tools. This is clear but relies on the reader inferring 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. Notably, obs-get-preview-scene exists as a closely related sibling, and the description does not explain the difference between 'active' (program) and 'preview' scenes, nor when an agent should prefer 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe read operation. The description adds minimal behavioral context, not explaining return values or error conditions, but with annotations covering the safety profile, a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no waste. It directly states the action and target in a front-loaded manner. Perfectly concise for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema, full schema coverage, and clear annotations), the description is adequate. It doesn't specify return value format, but for a simple mute-state getter, this is acceptable. It could mention what a boolean return means, but completeness is generally fine at a 3.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the single parameter 'inputName' described as 'Name of input to get the mute state of'. The description adds little beyond the schema but is consistent. With full schema coverage, the baseline of 3 is justified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Gets the audio mute state of an input' uses a specific verb ('gets') and names the resource ('audio mute state of an input'). It clearly indicates the read operation it performs. It does not explicitly distinguish from sibling tools like obs-get-input-volume or obs-set-input-mute, but the verb+resource combination is clear enough, earning a 4 rather than a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. While sibling tools like obs-set-input-mute and obs-toggle-input-mute suggest related operations, the description does not mention when a simple get is appropriate or when to prefer it. This is a clear gap, earning a 2.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is known. The description adds no behavioral detail beyond the fact that it retrieves settings, and it does not mention return format, error behavior, or edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundant information. It is appropriately concise for a simple getter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, with one well-documented parameter and strong annotations, but there is no output schema and the description does not explain what the returned settings include or how invalid output names are handled. It is adequate for a basic read-only tool but lacks some contextual detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully covers the only parameter, outputName, with a description ('Output name'), giving 100% schema coverage. The description adds no additional parameter semantics beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Gets') and resource ('settings of an output'), clearly stating what the tool does. It also distinguishes itself from sibling tools like obs-get-output-status and obs-set-output-settings by focusing on retrieving settings rather than status or modifying them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as obs-get-output-status or obs-set-output-settings. It only restates the function without context, prerequisites, or exclusion criteria.
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 annotations already declare readOnlyHint=true and destructiveHint=false, so the description's job is to add context beyond that. It doesn't contradict annotations. However, it adds no extra behavioral information such as what fields are included in the status response (e.g., recording state, timecode, paused state), or potential errors. Since annotations cover the safety profile, the minimal description is adequate but not enriched.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence and front-loaded. It's concise and to the point, though it could be slightly more informative without becoming verbose. It doesn't waste words, making it effective for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no params, no output schema), the description is sufficient to convey the basic purpose. However, it lacks details on the return value format or what 'status' means specifically (e.g., active/paused/stopped). With no annotations beyond read-only, an agent might still need additional inference from the name and sibling patterns. Overall, it's minimally viable but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description doesn't need to explain parameters. The schema coverage is 100% (empty object), and the description adds no parameter info because there are none. Baseline for 0 params is 4, and the description doesn't detract from that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool gets the status of the record output, which is clear enough to distinguish from sibling tools like obs-get-stream-status, obs-get-virtual-cam-status, or obs-get-replay-buffer-status. It's a specific verb+resource, though it could benefit from mentioning the output type or recording specifics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like obs-get-output-status or obs-get-record-status (which is this tool itself). It doesn't mention when to check record status, whether it should be used before starting/stopping recording, or if there are prerequisites. 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide idempotentHint=true and destructiveHint=false, but the description adds no additional behavioral context such as window behavior, effect of invalid parameters, or side effects. No contradiction exists, but the description contributes nothing beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence that conveys the core purpose with no filler or redundant information. 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/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple open-projector action, the description and schema are minimally sufficient. However, there is no mention of when to use this tool, what happens when the projector opens, or any side effects, leaving some gaps for an agent selecting among many similar OBS tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully covers all three parameters with descriptions, including the enum values for videoMixType and the meaning of monitorIndex. Since schema description coverage is 100%, the description does not need to add parameter details, and the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Opens a projector') and the target resource ('a specific output video mix'), which distinguishes it from the sibling obs-open-source-projector. The verb and object are specific 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as obs-open-source-projector, nor does it explain how to choose among the video mix types. There is no context about 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?
The description 'Resumes the record output' adds no behavioral detail beyond what the annotations already imply (mutating, idempotent, non-destructive). It doesn't disclose what happens if called when not paused (no-op, error, etc.), which would add value. Since annotations exist, the bar is lower, but no extra context is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The one-sentence description 'Resumes the record output' is perfectly sized for a zero-parameter action. It's entirely free of fluff and front-loads the action, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool this simple, the description is nearly complete—it states the action unambiguously and needs no parameter or return-value documentation. However, it would benefit from a brief note on preconditions (e.g., 'only effective when recording is paused') to make it fully self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there's no parameter semantics for the description to elaborate on. The schema is fully complete at 100% coverage, earning the baseline score of 4 for no-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Resumes the record output' uses a specific verb (resumes) and resource (record output), making the tool's function immediately understandable. While it's not a tautology—it clarifies the action on the recording output—it doesn't explicitly contrast with similar siblings like obs-start-record or obs-toggle-record.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like obs-pause-record or obs-stop-record. The description doesn't mention prerequisites (e.g., 'use after pausing') or exceptions, leaving the agent without explicit direction on 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?
The annotations indicate readOnlyHint=false and idempotentHint=false, implying a mutating, non-idempotent operation, but the description adds no extra details about side effects, rate limits, or whether captions are replaced or appended. It does not contradict annotations, but fails to enrich transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that directly states the action and target. It is concise with no redundancy or irrelevant information, making it easy to parse and understand.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple 'send' action, but it omits context such as error conditions, requirements (e.g., must be streaming), or whether the caption replaces or appends to existing captions. Given the tool's simplicity, the description is minimally complete but could be more informative.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the single parameter 'captionText' as 'Caption text to send', and the tool description repeats this without adding new details (e.g., length limits, encoding, or special formatting). With high schema coverage, the baseline is 3, and the description adds no additional value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: sending CEA-608 caption text over the stream output. It uses a specific verb ('sends') and resource ('stream output'), distinguishing it from sibling tools that handle scenes, inputs, or streaming controls.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives. It lacks context about prerequisites (e.g., active stream, caption format) or conditions under which it should be invoked. Usage is implied but not explicitly stated.
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?
Annotations already convey that this is a mutating, non-destructive, idempotent operation. The description correctly aligns with those annotations and adds the nuance of 'current active scene', but it does not disclose error behavior (e.g., invalid scene name) or side effects beyond the state change. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that states the verb and target with no filler. It is appropriately minimal for a simple setter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with full schema coverage and safety annotations, the description is mostly adequate. It is incomplete because it omits the important relationship to preview scene / studio mode and does not mention that valid scene names must come from an existing scene (e.g., via obs-get-scene-list).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the sceneName parameter is already described as 'The name of the scene to set as current'. The description adds no extra meaning about parameter source, exactness, or relation to obs-get-scene-list, so it does not go beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Set') and resource ('current active scene in OBS'), and 'active' helps distinguish it from the sibling obs-set-preview-scene. However, it does not explicitly contrast it with preview-scene or studio-mode behavior, so it stops short of full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. Given the sibling obs-set-preview-scene, the agent may not know that 'current active scene' means the program scene and that in studio mode there is a separate preview scene. Prerequisites like the scene needing to exist are also absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false. The description adds no behavioral context beyond the obvious mutation implied by 'Set' – it does not explain that this fully replaces the track enable state, requires all six tracks, or has side effects. Since the description adds nothing beyond what annotations provide, it falls short.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that directly states the tool's purpose. Every word earns its place, and it is front-loaded with the core functionality. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, one nested object with six required booleans), the schema provides thorough parameter details and the annotations cover safety traits. The description offers a minimal but adequate summary, yet it could mention that it fully configures the track state or advise pairing with the getter. It is functional but not rich.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description itself does not add any parameter-specific meaning; it relies on the thorough schema descriptions for inputName, inputUuid, and inputAudioTracks. No additional semantic detail is provided, so a baseline score is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Set) and the resource (enabled audio tracks for an input). It is specific and distinguishes from sibling tools like obs-get-input-audio-tracks (retrieval) and obs-set-input-audio-monitor-type (a different audio property). 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention that this is the complement to obs-get-input-audio-tracks, nor does it note any prerequisites or context such as needing to specify all six tracks. The usage context is entirely implied from the name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond the annotations. It doesn't disclose that the filterIndex must be within the current number of filters, nor any side effects on filter ordering. Annotations already declare idempotentHint=true, but the description contributes no additional 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no filler, front-loading the action and resource. This is perfectly sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with complete schema and annotations, the description is minimally adequate. However, it lacks guidance on valid index ranges, the optional canvasUuid parameter, and how this tool fits into filter management. It meets the minimum viable bar but leaves clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all four parameters with descriptions (100% coverage), so the description doesn't need to add parameter details. It only restates that filterIndex is the 'new index position,' which adds no extra meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Sets' and clearly identifies the resource: 'the index position of a filter on a source.' This distinguishes it from sibling filter tools like obs-set-source-filter-settings or obs-set-source-filter-enabled, which focus on other attributes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention that this tool reorders filters, requires an existing filter, or suggest how to discover valid indices. The description 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?
The description adds almost no behavioral context beyond the annotations: readOnlyHint=false already signals a state change, and the description merely restates that it starts something. It does not disclose error behavior when already recording, where output goes, or whether the recording must be configured first.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no filler or redundant detail. It is appropriately sized for a zero-parameter tool and immediately front-loads the action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity—no parameters, no output schema, and minimal annotation—the description is nearly complete for invocation purposes. It could mention recording-state preconditions, but the name, title, and sibling set provide enough context for a competent agent to select and call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and 100% schema coverage, so the description bears no obligation to explain parameters. The absence of parameters is itself fully documented by the schema, making the description's silence acceptable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Starts the record output' identifies a clear action ('starts') and a resource ('record output'), and the verb distinguishes it from toggle/stop siblings. It is slightly domain-specific and does not explicitly name 'recording' or contrast with obs-toggle-record, but the title and context make the purpose clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus obs-toggle-record, obs-stop-record, or obs-start-output. The description only states the action and does not mention preconditions such as 'only when recording is not already active'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare idempotentHint=true but destructiveHint=false. The description is very brief and doesn't disclose behavioral consequences beyond stopping output. It doesn't mention that stopping the buffer may discard the buffered content unless saved first (which is implied by siblings like obs-save-replay-buffer). It also doesn't state whether this affects other outputs. The description adds minimal value beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly states the purpose. It's front-loaded and contains no unnecessary words, effectively communicating the tool's function without filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is a simple action (no params, no output schema), the description is brief but lacks context about the tool's effect in the broader workflow. It doesn't explain the relationship to saving the replay buffer or potential data loss, which would be useful in the context of OBS replay buffer management. With no annotations covering these aspects, the description should have offered more.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100% (empty schema means no parameters to document). The description doesn't need to explain parameters, and a baseline of 4 is appropriate for a no-parameter tool that is adequately described.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Stops the replay buffer output' clearly states the action (stop) and the resource (replay buffer). It distinguishes from sibling tools like obs-start-replay-buffer and obs-toggle-replay-buffer by specifying the stopping action, though it could be more explicit about the context (e.g., stopping recording to a buffer for future saving).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when the replay buffer is active, but doesn't explicitly state when to use this vs. obs-save-replay-buffer or obs-stop-record. It doesn't mention prerequisites like having a running replay buffer or that stopping may discard unsaved content. It could better differentiate from related stop/save 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?
The description does not contradict the annotations; it aligns with readOnlyHint=false, idempotentHint=false, and destructiveHint=true. However, it adds little beyond 'triggering by name' and does not warn that the triggered hotkey may perform arbitrary or destructive actions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundant explanation. 'Triggers a hotkey using its name' is appropriately sized for the simplicity of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and the annotations provide useful safety context, but the description would be more complete if it pointed to hotkey discovery via obs-get-hotkey-list or warned that triggering a named hotkey may yield arbitrary side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so hotkeyName and contextName are already described in the input schema. The tool description only reinforces that triggering is name-based and contributes no additional parameter-level insight beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Triggers a hotkey using its name.' It also distinguishes this from the sibling obs-trigger-hotkey-by-key-sequence by emphasizing name-based triggering, though the wording mostly restates the tool title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. It does not mention that hotkey names can be discovered via obs-get-hotkey-list, nor does it contrast with obs-trigger-hotkey-by-key-sequence.
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 annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description does not need to repeat the safety profile. The description adds no additional behavioral context beyond these hints (e.g., what status fields are returned). It does not contradict the annotations, so a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence—"Gets the status of the replay buffer output"—with zero wasted words. It fully conveys the core function in a front-loaded, efficient manner.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no parameter details, the description is the only source for expected return values. It only says it 'gets status' but does not describe what statuses exist (e.g., active, replayAvailable) or the return format. For a monitoring tool, this is a gap that leaves the agent uncertain about the result's structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema coverage is 100% (no properties). The description adds no extra parameter semantics because there are none to explain. Since the schema handles everything, a baseline of 3 is fitting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets the status of the replay buffer output. While 'status' is not detailed, the verb 'gets' and resource 'replay buffer output' are unambiguous and distinguish it from sibling tools like ops-start/stop-replay-buffer or ops-get-last-replay-buffer-replay.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus other replay buffer operations (toggle, start, stop, save). The description does not mention alternatives or excluded use cases, leaving the agent to infer when a status query is 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?
Annotations already establish read-only, idempotent, and non-destructive behavior. The description adds the scope of the statistics (OBS, obs-websocket, current session) but does not disclose output format or potential performance implications. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with a front-loaded verb and object, containing no filler or redundant information. This is ideal for a parameterless read-only tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple parameterless stats tool, but because there is no output schema and 'statistics' is vague, the agent is left guessing what data will be returned. A brief enumeration of the categories would make it complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters and 100% schema description coverage, the baseline is 4. The description correctly needs no parameter details, and there is no ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Gets') and names the resource: statistics about OBS, obs-websocket, and the current session. However, 'statistics' is not elaborated and no distinction is made from sibling tools like obs-get-status or obs-get-version.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as obs-get-status or obs-get-version. The description only states what the tool does, leaving usage decisions to inference.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe, non-mutating operation. The description adds minimal extra context beyond the annotations, but it does not describe any side effects or prerequisites. Since it just re-states the read behavior, it offers limited 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that clearly states the action and resource. No filler or redundant information. It is appropriately sized for a simple read-only tool with no parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 params, no output schema), the description is minimally sufficient. However, it omits any indication of return value format or when to use it, which could be useful. The lack of output schema means the agent might want more info on what 'position' means, but the purpose is clear enough for basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and the schema coverage is 100% (empty). With no parameters, the description does not need to explain parameter meanings. The baseline for 0-param tools is 4, and the description adequately conveys the purpose without needing param details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool retrieves the current scene transition cursor position, which is a specific verb+resource. It clearly indicates a read operation on a particular OBS state, distinguishing it from sibling tools that manage transitions or other media cursor states.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description does not mention that it is a read-only query, nor does it contrast with related 'set' or 'offset' cursor tools like obs-set-media-input-cursor. It lacks any context about when to use it in a workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate the tool is read-only (readOnlyHint, idempotent, non-destructive), which is the key safety trait. The description adds minimal extra value beyond that, as it doesn't detail what happens if no transition is set or whether settings might be empty. With annotations covering the safety profile, a 3 is appropriate for the modest additional context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short, direct sentence that fully communicates the purpose. It's front-loaded and has no filler words. Perfectly concise for what it needs to convey.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, no output schema, and simple purpose, the description is mostly adequate. However, it doesn't explain what 'settings' means (e.g., JSON object of current transition properties) or clarify whether 'current transition' refers to the scene override or global. The tool is simple, but a tiny bit more context (like 'returns a map of key-value pairs') would make it more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, and schema coverage is 100% (trivially, since there are no params). With no parameters, the description doesn't need to elaborate on parameter behavior, and it correctly implies no arguments are needed. This is a baseline 4 for a zero-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get the settings of the current transition' clearly states the action (get) and the resource (settings of the current transition). It is concise and distinguishes itself from sibling tools like obs-set-transition-settings and obs-get-transition-list, though it doesn't explicitly mention which transition (current scene's transition or global). Still, it's specific enough for basic selection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs. alternatives. The description doesn't mention prerequisites or context, such as needing to ensure a current transition exists or that it differs from obs-get-transition-duration. There's no explicit exclusions or alternatives noted, leaving the agent to infer 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide idempotentHint=true (repeated calls are safe) and destructiveHint=false (non-destructive), which cover basic safety. The description does not add much beyond the annotations, but it does imply a state-change operation. It does not disclose potential side effects, such as requiring a restart of the input to take effect, or whether it affects output settings. Given the annotations cover the safety profile, this is acceptable but lacks extra 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that clearly states the action and target. It is front-loaded with the verb 'Set' and the resource. It uses no unnecessary words.FontWeight: There is no waste, but it lacks a bit of structure (e.g., no example of usage or output).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 3 parameters, one of which is an enum with many values. The description does not explain the impact of different modes or the context of when to use this tool (e.g., for asynchronous inputs only). There is no output schema, so the description does not need to explain return values, but it could clarify that the operation modifies the input's deinterlace property, affecting video processing. Given the moderate complexity, more completeness would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 67% description coverage: both inputName and inputUuid have descriptions, but inputDeinterlaceMode only has an enum without an explanatory description. The description of the tool adds no further meaning to the parameters. The enum values are self-explanatory as OBS deinterlace mode constants, but the description does not clarify what each mode does (e.g., YADIF vs. BLEND), which might be helpful. The baseline is 3 due to decent schema coverage, but no added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: setting the deinterlace mode of an input, with the specific resource (input) and the action (set mode). It distinguishes from related sibling tools like obs-get-input-deinterlace-mode (which retrieves) and obs-set-input-deinterlace-field-order (which sets a different property). The purpose is specific enough, though it doesn't mention that it only applies to asynchronous inputs, which is a key distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by specifying 'asynchronous input', which hints that it should only be used for inputs like video capture devices that support deinterlacing. However, it does not explicitly state when not to use it, such as for synchronous inputs or media files, nor does it mention any prerequisites like ensuring the input exists. There are sibling tools for setting related properties (e.g., field order), but no cross-referencing 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?
Annotations already indicate this is not read-only and is idempotent, providing safety profile. The description does not add much beyond that, but it doesn't contradict anything. It lacks information about failure modes, authentication requirements, or default behavior when only one of the volume parameters is provided. The description is adequate but doesn't enrich the annotations further.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is easy to parse and front-loaded with the verb. It avoids unnecessary words and conveys the primary action directly, which is efficient for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the moderate complexity of having two optional volume parameters and the presence of annotations, the description is minimally sufficient. It doesn't specify how to choose between dB and mul or what happens if both are provided, which could be useful. No output schema exists, so return value explanation isn't necessary, but more behavioral notes could enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers all three parameters with descriptions, giving 100% coverage. The description text adds no extra meaning beyond the schema, which already explains each parameter. Since schema coverage is high, baseline of 3 is appropriate; no additional clarification or examples are provided in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Sets the volume setting of an input' clearly uses a verb and resource, identifying its purpose. While it is clear, it does not provide additional detail to distinguish it from the sibling tool 'obs-get-input-volume' beyond the verb. It effectively conveys what the tool does, but lacks explicit differentiation or scope 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by stating it sets input volume, but it does not explain when to use this tool over alternatives or when not to use it. There is no mention of prerequisites, edge cases, or relationships to other tools like 'obs-get-input-volume'. It provides minimal contextual guidance 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?
The description does not add any behavioral context beyond the annotations. It does not mention side effects, permissions, or idempotency, which the annotations already partially cover.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no extraneous information. It directly states the purpose without elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for a simple setter: it specifies the action and the object. There is no output schema, and the description does not need to explain return values. However, it does not mention any preconditions or special cases, which could enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All parameters are described in the schema (100% coverage), and the tool description does not add or clarify any parameter behavior beyond the schema. Baseline of 3 applies because schema coverage is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (setting the locked state) and the target resource (scene item). It distinguishes from the getter sibling (obs-get-scene-item-locked) by using 'Set'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool, when not to, or which alternatives to consider. It is a generic setter without contextual advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations show readOnlyHint=false, destructiveHint=false, so the tool is intended to mutate state (splitting creates a new file) but is not flagged as destructive. The description doesn't disclose whether the split is immediate, whether recording must be active (prerequisite), or what happens to the original file. It lacks behavioral context like error conditions or effects on current recording. With no rich annotations, the description should provide more, but it provides only a basic action statement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no redundancy. It front-loads the action and achieves maximum clarity in minimal words, fully earning its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description adequately states the core operation. However, it lacks guidance on prerequisites (e.g., must be recording) or potential side effects, which would be expected for a mutating action. Given the simplicity and the context signals, the description is adequate but leaves room for more explicit behavioral guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema is empty. The description's mention of 'current file being recorded' clarifies the implicit subject of the operation, which is valuable context since there are no params. With 0 params, a score of 4 is appropriate because the description provides the only semantic anchor for what is being split.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Splits the current file being recorded') and the resource ('into a new file'). It uses a specific verb with a concrete outcome, and while it doesn't explicitly differentiate from sibling tools like obs-create-record-chapter (which marks a chapter but does not split the file), the purpose is distinct enough for an agent to infer the operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when recording is active and a file split is desired. It doesn't explicitly state when not to use it or mention alternatives like creating a chapter or toggling pause. But given the tool name 'Split Record File' and sibling context, the usage context is fairly clear without 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?
The description adds no behavioral context beyond what the annotations already state. Annotations indicate readOnly=false, idempotent=false, and openWorld=true, but the description does not clarify what side effects occur, whether starting an already-active stream errors, or what happens to the streaming session. It simply restates the action without additional disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no wasted words or filler. However, it largely duplicates the tool name and title, adding minimal new information, so it is concise but somewhat redundant rather than exemplarily informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with no parameters, no output schema, and annotations covering basic safety traits, so a short description can be adequate. Yet the description omits any guidance about preconditions (e.g., OBS connection, stream configuration) or the non-idempotent nature of the action, leaving the agent to infer important operational context from the tool name alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the input schema is empty, so the description is not required to explain parameter semantics. The baseline for a zero-parameter tool is 4, and the description does not need to compensate for any schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Start streaming in OBS' clearly states the specific action (start) and resource (streaming), leaving no ambiguity about the tool's core purpose. It distinguishes from siblings like obs-stop-stream, obs-toggle-stream, and obs-start-record 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as obs-toggle-stream or obs-start-record. There is no mention of prerequisites, such as requiring OBS to be connected or already configured, nor any indication that this tool may fail if already streaming.
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 annotations already indicate this is a non-read-only action, and the description adds the Studio Mode requirement, which is useful. However, it does not disclose what happens on success (e.g., transition occurs between preview and program) or what errors might arise if Studio Mode is not enabled. Given the annotations carry the safety profile, the description adds marginal but acceptable context, scoring a 3.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the action and the key prerequisite. It contains no fluff or redundancy, making it highly efficient and easy for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter action, the description is mostly sufficient—it names the action and a requirement. However, it lacks differentiation from the similar sibling tool 'obs-trigger-studio-transition' and does not describe expected behavior or potential failure modes when Studio Mode is disabled, leaving some ambiguity in execution context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline score of 4 applies. The description does not need to explain parameters since none exist, and the schema coverage is vacuous (100% with no properties). No additional semantic value is required or provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Trigger a scene transition in OBS' clearly states the verb and resource, making the purpose unambiguous. However, it fails to distinguish from the sibling tool 'obs-trigger-studio-transition', which likely serves a similar or identical function, thus missing the highest clarity score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides only a prerequisite ('Studio Mode must be enabled') but offers no guidance on when to use this tool versus alternatives like 'obs-trigger-studio-transition' or when not to use it. There is no mention of exclusions or fallback options, leaving the agent without clear contextual direction.
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?
Annotations already declare readOnlyHint, openWorldHint false, idempotentHint, and destructiveHint false, so the safety profile is well covered. The description adds no extra behavioral context like return shape or error behavior, but it does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with the verb and object front-loaded. Every word earns its place, and there is no redundant repetition of schema or annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and the annotations plus schema cover safety and the parameter adequately. However, the lack of usage alternatives and the absence of an output schema mean the description does not convey what the returned default settings look like or how to obtain valid inputKind values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the single inputKind parameter is fully described in the schema. The description merely restates 'input kind' without adding examples, allowed values, or format details, so it meets the schema baseline but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Gets') and the resource ('default settings for an input kind'). The phrase 'default settings' and 'input kind' distinguishes it from related siblings like obs-get-input-settings and obs-get-filter-default-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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives, such as when current input settings are needed instead of defaults. It also does not mention discovering valid input kinds via obs-get-input-kind-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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is known. The description adds minimal context ('asynchronous input') but does not describe return format, potential errors, or preconditions. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the action and resource. There is no redundant information or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple getter nature and strong annotations, the description is mostly adequate. However, it does not clarify that one of inputName or inputUuid must be provided, and with no output schema it omits what the return value looks like. This leaves minor but real gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with inputName and inputUuid both described. The tool description adds no extra parameter semantics beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb ('Get') and a specific resource ('deinterlace mode of an asynchronous input'), distinguishing it from sibling tools like obs-set-input-deinterlace-mode and obs-get-input-deinterlace-field-order. It states exactly what information is retrieved.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. It does not mention that the input must be identified by name or UUID, nor does it contrast with the setter variant. The usage context is only implied by the verb and resource.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds minimal behavioral context beyond that, but doesn't contradict annotations. It doesn't mention return format or units, but with annotations covering safety, a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with zero waste. It's front-loaded with the action and resource, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with one parameter and good annotations, the description is adequate. It doesn't explain return values, but there's no output schema and the tool is simple. It could mention that volume is typically in a specific range (e.g., 0.0-1.0) or that it returns a float, but this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter inputName, which is well-documented. The description adds no additional parameter semantics beyond what the schema provides, so baseline 3 is correct.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets the current volume setting of an input, which is specific and distinguishes it from sibling tools like obs-set-input-volume or obs-get-input-mute. However, it doesn't explicitly mention the resource type (input) in the verb phrase, but the title and schema make it clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving volume settings, but doesn't provide explicit guidance on when to use this vs alternatives. It doesn't mention that this is a read-only operation or contrast with set-input-volume, though the annotations and sibling names provide some 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is established. The description adds the lookup-by-source-name behavior but does not disclose what happens on multiple matches, missing matches, or how UUIDs interact with names. No contradiction exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single 11-word sentence that front-loads the action and primary input. There is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only lookup with six optional parameters and no output schema, the description is minimal. It does not explain the return format, multi-match handling, or how to combine scene and source identifiers, leaving those details to the schema. Annotations cover safety and schema covers parameter semantics, making it minimally complete but not rich.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so each of the six parameters is already described. The description only adds that the search is 'by its source name', which reinforces sourceName but offers no additional semantic detail about identifier precedence, match offset, or scene selection.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action: 'Get the ID of a scene item' and the key input: 'by its source name'. It is specific and distinguishes from sibling tools such as obs-get-scene-item-source (inverse operation) and obs-get-scene-items (list operation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention related tools like obs-get-scene-item-source or obs-get-scene-items, nor any exclusions or prerequisites beyond the implied lookup scenario.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds no extra behavioral context (e.g., return format, error handling, or whether the source is a name or object). Given the annotations cover the main risks, a score of 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, direct and efficient. There is no redundant information, and it is appropriately front-loaded with the core purpose. It earns a perfect score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only getter with well-documented parameters, the description is minimally adequate. However, it does not clarify what the 'source' refers to (e.g., a string name, an object, or a reference), nor does it explain the relationships between sceneName, sceneUuid, and canvasUuid. Since there is no output schema, more context would be helpful, but the tool's simple nature lowers the requirement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all four parameters, including names and UUIDs. The description does not add any meaning beyond the schema—it only restates that the tool retrieves a source associated with a scene item. Baseline 3 applies since the schema already documents each parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get the source associated with a scene item' clearly states the action (get) and the target (source of a scene item). It is specific enough to distinguish from sibling tools like obs-get-scene-item-id or obs-get-scene-item-transform, which deal with different attributes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No information is provided about when to use this tool versus alternatives. It does not mention prerequisites, selection criteria among scene identifiers, or scenarios where another getter might be more appropriate. The usage context is entirely 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond the annotations; it simply restates the title. It does not mention side effects, error behavior, or that it manipulates the OBS UI. Annotations already indicate idempotency and non-destructiveness, so there is no contradiction, but the description itself contributes 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single succinct sentence with no filler words, front-loading the action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool, the description is mostly adequate, but it fails to clarify whether at least one parameter is required, or which to prefer when both are provided. It also does not state what happens if the input is not found.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides full descriptions for both parameters, achieving 100% coverage. The tool description does not add any additional semantic information about parameter usage or selection.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'opens' and identifies the resource 'filters dialog of an input', clearly distinguishing it from sibling tools like obs-open-input-properties and obs-open-input-interact.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states what the tool does but does not provide explicit guidance on when to use it vs alternatives, nor does it explain which parameter to use (inputName vs inputUuid) or any 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?
The description states the primary side effect—opening a dialog—and does not contradict the annotations, which mark it as idempotent and non-destructive. However, it adds little beyond those annotations, such as UI availability, failure modes, or why this differs from programmatic interaction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler words. It efficiently states the verb and resource, making it appropriately concise for a tool of this simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple action, the schema, and the annotations, the description is minimally viable. It lacks guidance on how to choose this over sibling open-dialog tools or whether an identifier is required, but it covers the core purpose adequately for a straightforward operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for both inputName and inputUuid at 100% coverage, so the schema carries the parameter-documentation burden. The description adds no additional parameter semantics or clarification about using one identifier versus the other.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Opens' and identifies the exact resource, 'interact dialog of an input.' This clearly distinguishes it from sibling tools like obs-open-input-properties and obs-open-input-filters, which open different input dialogs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool instead of other input dialog-opening siblings. No prerequisites, exclusions, or alternative recommendations are provided, so the usage context must be inferred solely from the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false. The description adds no extra behavioral context, such as what happens to scene items contained in the scene or whether the scene must not be currently active. The description merely restates the action without elaborating on side effects or requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that immediately conveys the purpose. It has no wasted words and is appropriately front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with good annotations covering destructiveness and idempotency, and parameters are fully described. However, the description does not mention the destructive side effects on contained scene items or any constraints (e.g., cannot remove an active scene), which would be useful context for a destructive operation. It is adequate but has gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both sceneName and canvasUuid are documented. The description does not add any additional meaning beyond the schema's parameter descriptions, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Remove a scene from OBS', using a specific verb 'remove' and resource 'scene'. It distinguishes from siblings like obs-create-scene and obs-set-scene-name, which handle other scene operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for removing scenes, but it does not mention when to use it versus alternatives (e.g., obs-remove-scene-item for removing items within a scene) or any prerequisites like the scene needing to exist. No explicit when-not guidance 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?
Annotations already indicate this is a mutating, idempotent, non-destructive operation. The description adds the specific scope 'asynchronous input' but does not disclose prerequisites, error behavior, or what happens if the input is not asynchronous. It does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that directly states the action and target. 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/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter, the description and annotations provide a basic understanding, but the lack of guidance on input identification and the absence of any mention of related getter/set operations make it only minimally complete. No output schema exists, so a bit more context about expected behavior would help.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover inputName and inputUuid, and the enum for inputDeinterlaceFieldOrder is self-explanatory. The description adds no extra meaning about parameter relationships, such as whether inputName or inputUuid is required to identify the target input, which would be valuable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('set') and names the exact resource ('deinterlace field order of an asynchronous input'), which clearly differentiates it from the sibling getter and the related set-input-deinterlace-mode tool. The title and description align and leave little 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. It does not mention the getter for reading the current field order, nor does it explain when setting field order is appropriate or how it relates to other deinterlace settings. The usage context is entirely implied.
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?
Annotations provide idempotentHint=true and destructiveHint=false, so the tool is safe to call multiple times without side effects. The description doesn't contradict annotations. It adds context that it affects 'record output' directory, which is useful. The description doesn't mention any side effects like changing the directory affecting future recordings, but given idempotency and non-destructive hints, this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that conveys the purpose effectively. It is front-loaded with the verb 'Sets' and the resource. No unnecessary words. It's appropriately sized for a simple setter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a simple setter with one parameter, the description covers the essential purpose. The annotations provide idempotency and non-destructive hints. The sibling tools provide context for what other related operations exist. The description doesn't need to explain return values since there's no output schema. It's complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage for the parameter 'recordDirectory' with description 'Output directory'. The description says 'Sets the current directory that the record output writes files to' and essentially reiterates the same meaning. The parameter description is minimal but clear. The tool description adds little beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does: it sets the current directory for record output files. It specifies the resource (record output) and the action (sets directory). It's distinguishable from siblings like obs-get-record-directory (which gets the directory) and obs-set-output-settings (which sets output settings in general).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: it sets the directory for recording output. It doesn't explicitly mention when to use it vs alternatives like obs-get-record-directory or obs-set-output-settings. However, the purpose is clear enough that an agent can infer the appropriate use case. No explicit exclusions or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already communicate the important behavioral traits: readOnlyHint=false, idempotentHint=true, and destructiveHint=false. The description adds no further behavioral context, such as effects on scene references or return behavior, but it is consistent with the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence, 'Rename an OBS scene,' with no filler or redundancy. Every word contributes to the meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, and annotations plus full schema coverage cover much of the needed context. However, the description omits how to identify the target scene and does not clarify why only newSceneName is required, leaving a meaningful gap for an agent trying 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/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover 100% of parameters and provide basic definitions for sceneName, sceneUuid, canvasUuid, and newSceneName. The description itself adds no parameter-level meaning, so the baseline score of 3 applies; it also does not clarify that at least one scene identifier should be supplied even though only newSceneName is marked required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses the specific verb 'Rename' and the resource 'OBS scene', making the operation unambiguous. It also distinguishes this tool from sibling scene tools like obs-create-scene, obs-remove-scene, and obs-set-current-scene.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance about when to use this tool versus alternatives, nor does it mention prerequisites such as needing an existing scene identifier. The only usage clue is the verb in the description, so an agent must infer context from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the 'clear' behavior beyond the tool name, which is useful, but it does not disclose any further behavioral traits. Annotations already cover idempotency and non-destructiveness, so the description adds limited value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It conveys the essential purpose efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and schema/annotations are strong, but there is no clarification about how to identify a scene given the all-optional parameters and the sceneName/sceneUuid/canvasUuid relationship. This leaves some ambiguity for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the description does not need to repeat parameter details. It adds no extra semantic nuance beyond the schema, matching the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set or clear') and the specific resource ('transition override for a scene'). This distinguishes it from related tools like obs-get-scene-transition-override and obs-set-current-transition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not explain when to use this tool versus global transition controls, nor does it mention alternatives 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?
Annotations are all false (readOnlyHint: false, idempotentHint: false, destructiveHint: false), indicating a state-changing operation, but the description adds no behavioral context beyond the verb 'set'. It does not explain side effects, prerequisites (e.g., studio mode requirement), or potential impact on transitions. The 'optionally release' is redundant with the schema parameter 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the core action and resource. No redundant words or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and full schema coverage, the description is minimal but sufficient for a basic setter. However, it lacks context about when the T-bar is relevant (e.g., studio mode) and what the release behavior means functionally. Since no safety hints are provided by annotations, a bit more behavioral context would be expected, but the current level is adequate for a simple operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both `position` and `release` already documented. The description adds no extra parameter semantics beyond what the schema provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (set) and the resource (OBS Studio Mode T-Bar position), with an additional nuance of optionally releasing. It distinguishes from sibling tools like obs-trigger-studio-transition, which is about triggering transitions, not setting the T-bar position directly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives. It implies usage in the context of OBS studio mode T-bar control, but lacks explicit guidance on scenarios or exclusions. No mention of when not to use it, such as when not in studio mode.
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 adds minimal behavioral detail beyond the annotations. It does not explain that the tool flips the current streaming state (on→off, off→on) or any side effects, despite openWorldHint suggesting non-trivial behavior. No contradiction with annotations, but little added value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no fluff or redundancy, perfectly sized for a simple toggle operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple tool but lacks explicit context about the state-dependent behavior (e.g., 'if streaming is active, stops it; otherwise starts it'). With no output schema, indicating expected outcomes would improve completeness, but for a basic toggle it is minimally sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema description coverage is trivially 100%. Since there are no parameters to describe, the baseline of 4 is appropriate; the description correctly omits parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (toggle) and the resource (streaming state) in OBS, distinguishing it from sibling start/stop tools by implying a binary flip of the current state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus obs-start-stream or obs-stop-stream. It does not mention alternatives, current state prerequisites, or conditions for use, leaving the agent to infer 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe read operation. The description doesn't contradict annotations and adds no additional behavioral context (e.g., what the return value looks like, whether it requires exposing an input, units of the offset). Adding nothing beyond the annotations, it neither exceeds nor falls short of expectations for a tool with strong annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, perfectly front-loaded, with zero waste. It takes minimal characters to convey the essence of what the tool does. This is ideal for a tool with a single obvious parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with one parameter and strong annotations (readOnly, idempotent), the description is adequate. The only gap is that it doesn't describe the return value units or format (e.g., milliseconds), which could matter for an agent interpreting the result. But given no output schema exists and the tool is simple, this is a minor gap, not a critical one.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (the only parameter, inputName, has a clear description in the schema). The tool description itself doesn't add anything beyond what the schema already says, which is fine given the schema coverage. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets the audio sync offset of an input. It uses a specific verb ('Gets') and identifies the resource. However, it doesn't distinguish itself from sibling tools like 'obs-set-input-audio-sync-offset' (the getter vs setter distinction is implied but not explicit), so it loses a point for not actively differentiating from that near-sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: you'd call this when you need to read the current audio sync offset for a given input. It doesn't explicitly say when NOT to use it (e.g., you'd use set-input-audio-sync-offset to change it). With dozens of sibling getters for other input properties (volume, mute, etc.), the description doesn't help the agent navigate that decision tree beyond what's 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?
The annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds no extra behavioral details such as error handling, return format, or what happens if the slot does not exist, but does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the action and resource. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with 2 well-documented params and safety annotations, the description is nearly sufficient. It lacks explicit mention of behavior when the slot is missing, but with no output schema, this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of the parameters with descriptions for 'realm' and 'slotName'. The description adds no additional semantic meaning beyond the schema, so it meets the baseline but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Gets') and the resource ('the value of a slot from the selected persistent data realm'), making it easy to distinguish from sibling tools like obs-set-persistent-data. It is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives. The description simply states what it does, but does not mention exclusions, prerequisites, or contrast with related getters such as obs-get-profile-parameter.
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?
Annotations already indicate readOnlyHint, idempotentHint, and non-destructive, so the safety profile is covered. Description adds that it returns an array, but does not mention error behavior (e.g., what happens if source is not found) or whether canvasUuid is optional. With annotations present, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is a single sentence, highly concise 'Gets an array of all of a source's filters'. No filler or repetition of the tool name. Perfectly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given good annotations (readOnly, idempotent), full schema coverage, and simple tool complexity (single required param), the description is sufficient. It clearly states the primary return type (array of filters). Missing minor details like 'all' implying completeness, but that's already in the description. No output schema, so no need to explain return structure beyond 'array'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with descriptions. The description adds no extra meaning beyond what the schema provides, so we use the baseline of 3. It doesn't clarify the role of canvasUuid (optional, for sources in specific canvas) or the format of sourceName beyond what the schema says.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it gets an array of filters for a source. Differentiates from siblings like obs-get-filter-kind-list (lists filter types) and obs-get-source-filter (gets a specific filter), though could be more explicit about 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving filters of a source, which is clear from the tool name. However, it doesn't explicitly mention when to use this instead of obs-get-source-filter or obs-get-filter-kind-list, nor does it indicate prerequisites like the source must exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds minimal behavioral insight beyond the name; it does not mention what happens if no transition is active, the return type, or any potential side effects. With annotations present, the description contributes little extra value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no wasted words. It front-loads the core action and object immediately, making it easy to scan. For a simple getter, this is appropriately sized and structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema, and strong annotations), the description provides sufficient context. It clearly states what is retrieved (the kind/type of the current transition). It could optionally mention the return format or error conditions, but these are not critical for an experienced agent, and the annotations along with the name carry the essential context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is empty with 100% coverage. Per the rubric, a baseline of 4 is appropriate for 0-param tools. Since there are no parameters to document, the description does not need to add anything, and the baseline holds.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (Get) and resource (the kind/type of the current transition), distinguishing it from sibling tools like obs-get-current-transition (which retrieves the full transition object) and obs-get-transition-list (which lists available transitions). It is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives. It does not mention scenarios where one would prefer obs-get-transition-settings or obs-get-current-transition, nor does it explain the context or prerequisites (e.g., needing an active transition). No exclusions or recommendations 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?
Annotations already declare destructiveHint=true and idempotentHint=true, covering the safety profile. The description adds no further behavioral details (e.g., permanence, handling of nonexistent filters), but it does not contradict the annotations, so a mid-range score is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no unnecessary words, perfectly sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation with complete schema and appropriate annotations, the description is mostly sufficient. It could optionally mention behavior when the filter doesn't exist or clarify the optional canvasUuid parameter, but these are minor gaps given the schema covers parameter semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides complete descriptions (100% coverage) for all three parameters, so the description adds no extra meaning. The baseline of 3 applies since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Removes a filter from a source' uses a specific verb ('removes') and resource ('filter', 'source') making the action unambiguous. It clearly distinguishes from sibling tools like obs-create-source-filter or obs-set-source-filter-enabled.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives like disabling a filter or clearing its settings. The description simply states the action without 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?
Annotations are all false (readOnly, openWorld, idempotent, destructive), but the description does not disclose any additional behavioral traits. It does not mention side effects (e.g., whether the buffer is cleared after saving) or requirements (e.g., buffer must contain data). It adds no value beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the action and subject. There is no redundancy or wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with no parameters and no output schema, so the description does not need to explain return values or complex behavior. However, it omits any mention of state changes or preconditions, which would be useful for an agent. Still, for a simple save action, it is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the schema coverage is trivially 100%. Baseline for 0 params is 4, and the description correctly does not attempt to explain nonexistent parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Saves) and the resource (replay buffer output), distinguishing it from siblings like get/toggle/start/stop replay buffer operations. It is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives. It simply states the action without context, such as prerequisites (e.g., replay buffer must be active) or when saving 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?
Annotations document idempotentHint=true, destructiveHint=false, and readOnlyHint=false, which already convey the safety and mutation profile. The description adds no behavioral context beyond 'switches', such as side effects on other settings, so it contributes only minimal value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence that conveys the essential action with no wasted words. For a simple setter tool, this is appropriately sized and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, one well-described parameter, and supportive annotations, the description is nearly complete. It lacks only minor context like 'switches the current/active profile' or 'profile must exist', but overall it is sufficient for an agent to understand the tool's purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single profileName parameter is already described as 'Name of the profile to switch to'. The description adds no additional parameter-level meaning, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Switches') and resource ('profile'), clearly indicating the action of changing the active profile. It is distinct from sibling tools like obs-create-profile, obs-remove-profile, and obs-get-profile-list, and the title reinforces 'Set Current Profile'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as obs-get-profile-list or obs-create-profile. The description states the action but gives no context about prerequisites, such as needing to list available profiles first or that the profile must already exist.
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?
Annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=true, so the safety profile is covered. The description adds no additional behavioral context beyond the simple action, such as side effects or return behavior, but it does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler or redundancy. It front-loads the action and resource clearly, which is ideal for a simple setter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity, two fully documented parameters, and meaningful annotations, the description is largely sufficient. It lacks a bit of contextual guidance around when to adjust audio balance versus related audio tools, but the schema and annotations carry most of the required detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and both parameters are already clearly documented: inputName and inputAudioBalance with a 0.0-1.0 range. The description adds no extra parameter meaning, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly uses a specific verb ('Sets') with a specific resource ('audio balance of an input'), making the tool's function immediately understandable. It also distinguishes itself from the sibling tool obs-get-input-audio-balance by its setter intent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as obs-get-input-audio-balance or obs-set-input-audio-tracks. There are no exclusions, prerequisites, or context clues beyond the verb 'Sets,' so the usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is not read-only, not idempotent, and not destructive, but the description adds no behavioral context beyond restating the action. It does not say what happens if the virtual cam is already running, whether prerequisites exist, or what side effects 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with the core action front-loaded. Every word contributes meaning, and there is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema command, the description is nearly complete. It explains the core operation but lacks a brief note contrasting with toggle or stop, which would strengthen completeness for an agent selecting among siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters and 100% schema coverage, there is no parameter meaning to clarify. The baseline of 4 is appropriate because the description need not compensate for undocumented inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action with a specific verb and resource: 'Starts the virtualcam output.' This distinguishes it from sibling tools like obs-toggle-virtual-cam, obs-stop-virtual-cam, and obs-get-virtual-cam-status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus alternatives. It does not mention obs-toggle-virtual-cam or obs-stop-virtual-cam, 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?
Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds no behavioral details beyond this, such as what happens on failed connection (exception vs false return) or whether it might block. Since it adds no new information, it fails to go beyond the structured data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no fluff. It front-loads the purpose immediately and contains no unnecessary information. Perfectly appropriate for a tool this simple.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, no output schema, and a clear, straightforward purpose, the description provides adequate information on its own. However, it omits what the result indicates (e.g., success/failure semantics), which could be helpful, but this is not critical for a basic connectivity test. The overall context is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. No parameter documentation is needed, and the description correctly focuses on the tool's action rather than parameters. There is nothing to add about parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb and resource: 'Test the connection to OBS WebSocket'. It is distinguishable from all sibling tools, which are all about specific actions or queries, making this the only connectivity check.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description only states what it does, not when it should be called (e.g., before other OBS operations to verify reachability) or any prerequisites. This gap is significant given the tool's diagnostic nature.
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 annotations already communicate that this is not read-only, not idempotent, and not destructive. The description adds the domain and behavior of flipping the mute state, but it does not explain error conditions, return behavior, or that repeated calls alternate the state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short, direct sentence. It contains no redundant phrasing or filler and places the action and resource at the center.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with strong annotations and full schema coverage, the description is nearly complete. It lacks sibling guidance and any note about behavior when the input does not exist, but those gaps are minor given the tool's low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the single inputName parameter is already documented. The description adds no deeper semantic meaning about how the name must match an existing OBS input, but it also does not need to compensate for missing schema detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and resource: toggling the audio mute state of an input. It clearly distinguishes from sibling tools like obs-get-input-mute and obs-set-input-mute by signaling a flip rather than a read or set operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool instead of obs-get-input-mute or obs-set-input-mute, nor any mention that the input must already exist. The agent is left to infer the usage 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are present: readOnlyHint=false, destructiveHint=false, idempotentHint=false. The description does not contradict these annotations. Since it is a toggle operation, it is understood to be a state-changing action with no destructive or idempotent guarantees, but the description does not add further behavioral context such as what happens if the replay buffer is not enabled or whether the toggle returns the new state. The annotations carry most of the burden, and the description adds minimal additional value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the action and target: 'Toggles the state of the replay buffer output'. It wastes no words and is appropriately sized for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema), the description is minimal but adequate. However, in the context of many sibling tools for replay buffer control (start, stop, save, get status), it lacks context on how toggling fits into the workflow, such as whether the agent should check status first or what happens if the buffer is already in the desired state. The description could be slightly more complete by mentioning these aspects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema explicitly shows an empty properties object with 100% schema description coverage. The description does not need to add parameter details because there are none. Baseline for zero parameters is 4, which is appropriate here as the description correctly implies no parameters are required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it toggles the state of the replay buffer output with a specific verb and resource. However, it does not explicitly differentiate from sibling tools like obs-start-replay-buffer, obs-stop-replay-buffer, and obs-get-replay-buffer-status, which are closely related and could benefit from a clearer distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating 'toggles', suggesting it is used to flip the current state of the replay buffer. It does not provide explicit guidance on when to use this tool versus starting or stopping the replay buffer directly, nor does it mention any prerequisites or context in which toggling is preferred over explicit start/stop actions.
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?
Annotations already mark this as non-read-only and non-idempotent; the description adds useful context that the new input also appears as a scene item in the target scene. It does not disclose failure conditions, default item enabled state, or the effect of inputSettings, but annotations lower the transparency burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One well-formed sentence, front-loaded with the verb and object, no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given six parameters and a nested inputSettings object, the description plus the well-described schema is minimally sufficient, but it offers no guidance on how to determine inputKind values or structure settings. No output schema exists, so return-value documentation is not required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all six parameters. The description's mention of 'scene item' and 'specified scene' reinforces sceneName/inputName but adds no parameter-level meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action — creating a new input — and its notable side effect of adding it as a scene item to the named scene. The resource type 'input' distinguishes it from sibling creation tools such as obs-create-scene-item and obs-create-scene.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case: when you need a new input placed into a scene. However, it provides no explicit when-not-to-use guidance or alternative tool names, so the usage context is implied rather than fully directive.
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?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is established. The description adds minimal behavioral context beyond what's in the annotations. It does not mention any side effects, prerequisites, or related status flags that might be expected, but given the annotations, a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is direct and front-loaded with the main action. There is no wordiness or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema, annotations present), the description is adequately complete. It tells the agent what the tool returns (monitor info) without needing extra explanation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, which is a special case. The baseline for 0 params is 4. The description adds meaning beyond the schema (which is empty) by specifying the output domain (monitors and their information).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool gets a list of connected monitors and information about them, which is clear and specific. It distinguishes from sibling tools generally oriented around scenes, sources, and outputs, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies it's used to retrieve monitor information for display or configuration, but it doesn't explicitly state when to use this tool versus others like obs-get-virtual-cam-status or obs-get-output-list. No exclusions or alternative names are provided, making 'when to use' only 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds that it returns duration in milliseconds, which is useful but minimal. It doesn't mention potential errors (e.g., no current transition) or whether it returns a default value, but given the annotations, a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly states the tool's function. No filler or redundant information. It is appropriately front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no parameters and no output schema, the description is nearly complete. It specifies the resource, attribute, and unit. It could mention that it returns the current transition's duration, but the description already implies 'current transition'. Given the simplicity, this is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema description coverage is 100% (vacuously). The description correctly notes the output unit (milliseconds), which adds meaning beyond the empty schema. Since there are no parameters, the description's job is minimal, and it fulfills it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the duration of the current transition in milliseconds. It specifies the resource (transition) and the attribute (duration), which is clear and distinct from sibling tools like obs-get-transition-settings or obs-set-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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for reading transition duration but does not explicitly state when to use this over alternatives. It doesn't mention that this is a read-only query or that it complements obs-set-transition-duration. No exclusions or alternative tool references 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?
Annotations declare readOnlyHint=true and idempotentHint=true, so the description only needs to confirm safety. It does so implicitly by stating 'Get all available' without explicit mention of non-destructiveness, but the annotations cover this. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that clearly states the tool's action and result. No fluff or repetition; it is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list operation with no parameters and no output schema, the description is adequate. It covers the essential purpose, and the annotations provide safety context. Complete enough 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/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the description needs no parameter details. The schema is empty, and there is nothing to explain. The description adds no parameter-related knowledge, but given no parameters, a score of 4 is appropriate (baseline for 0 params).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all available OBS transition kinds, correctly implying a read operation. It distinguishes from sibling tools like obs-get-filter-kind-list and obs-get-input-kind-list by specifying 'transition 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description is clear about its purpose but does not explicitly state when to prefer this tool over alternatives. It implies usage for retrieving transition kinds, which is sufficient for a simple list 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?
Annotations already indicate readOnlyHint=false (mutable) and idempotentHint=true. The description confirms the mutation action and the setting behavior, but doesn't add extra context like side effects or the exact enum values. It doesn't contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the action. It's efficient and to the point, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (2 required params, no output schema), the description is complete. It doesn't explain the return value, but that's not needed since it's a setter. The annotations and schema fill in the rest.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage for both parameters, with descriptions of 'inputName' and 'monitorType'. The description adds no extra meaning beyond the title and schema, but the schema itself is sufficient. Baseline 3, but the description's clarity on the setting action slightly enhances usage understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Sets the audio monitor type') and the resource ('an input'), which distinguishes it from sibling tools like obs-get-input-audio-monitor-type. However, it doesn't explicitly mention the valid values for monitorType, which are already in the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (setting audio monitor type for an input), but doesn't provide explicit guidance on when to use this vs alternatives or any prerequisites. Sibling tools like obs-get-input-mute or obs-set-input-volume are related but context-specific, and no exclusions are stated.
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?
Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false, so the description is not required to restate these. It adds no further behavioral context beyond the action itself, such as immediate rendering effects or dependencies on source state. With annotations covering the safety profile, this is adequate but not enriched.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler or redundancy. It states the core purpose immediately and contains no unnecessary words, making it highly efficient for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter tool with complete parameter coverage and annotations, the description is fully sufficient. There is no output schema to document, and all required context is provided by the structured fields. The tool's low complexity does not demand additional explanatory content.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all four parameters clearly described (sourceName, filterName, filterEnabled, canvasUuid). The description does not add any additional semantic detail beyond what the schema provides, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Sets the enable state of a source filter' clearly identifies the action (sets) and the resource (source filter's enable state). It distinguishes from sibling tools like obs-set-source-filter-settings or obs-set-source-filter-name by focusing specifically on the enabled/disabled state. The verb is specific and the scope is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus the many related filter tools (e.g., obs-set-source-filter-settings, obs-get-source-filter). It merely states the action without explaining contexts like toggling visibility or prerequisites (e.g., filter must exist). No exclusions or alternatives are mentioned.
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 annotations already declare this as a write, non-destructive, idempotent operation. The description adds valuable context that the tool always operates on the 'current transition', which is not evident from annotations or the schema. This clarifies the scope of the mutation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence using clear verb-object phrasing. Every word contributes to meaning, and there is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one generic object parameter, no output schema), the description is minimally adequate. However, it does not describe what kinds of settings are valid, how to discover them, or mention the related 'obs-get-transition-settings' for reading current values, leaving some gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (the only parameter, 'transitionSettings', has a description). The tool description adds no further explanation about the expected structure or valid keys within the settings object, so it does not exceed the baseline set by the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Set' and identifies the resource as 'settings of the current transition'. This clearly distinguishes it from the sibling tool 'obs-get-transition-settings' (which retrieves settings) and other transition-related tools like 'obs-set-current-transition'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that to read current settings you should use 'obs-get-transition-settings', nor does it state any prerequisites or exclusions. The usage is only implied by the verb 'Set'.
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?
Annotations already declare readOnlyHint=false, indicating a mutating operation, and destructiveHint=false, indicating no destructive side effects. The description adds that it modifies the file being recorded, which is consistent with the annotations. However, it does not disclose any additional behavioral traits such as failure modes (e.g., if recording is inactive), permission requirements, or whether the chapter marker is inserted at the current playback position. Since annotations cover the mutability baseline, the description provides minimal extra context, scoring a 3.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler words. It delivers the essential information in a concise, front-loaded manner. Every word adds value, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite being a simple tool with one parameter, an output schema, and annotations, the description adequately conveys the action and context. It mentions the recording context implicitly, which is a key prerequisite. However, it could explicitly state the requirement that recording must be active, but given the tool's simplicity and annotations, it is sufficiently complete for an agent to understand its basic function.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: the only parameter 'chapterName' is fully described in the schema with 'Name of the new chapter'. The tool description does not add any further semantic detail about the parameter, but the schema already conveys its meaning. According to the guideline, with high schema coverage, the baseline is 3, and the description does not exceed that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Adds'), the resource ('new chapter marker'), and the context ('to the file currently being recorded'). It is specific and distinct from sibling tools like obs-split-record-file, as adding a chapter marker is a different operation. The verb+resource structure 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage during recording ('currently being recorded') but does not explicitly state when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions. It provides no guidance on when not to use it or how it differs from related tools like obs-split-record-file. The context is clear enough for basic use but lacks explicit alternatives or caveats.
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 'preserving its transform and crop,' which is a key behavioral guarantee beyond what the annotations (all false) reveal. However, it does not disclose other side effects, error conditions, or side effects like whether linked settings are copied. Since annotations provide no safety context (all false), the description carries the burden but covers only part of the behavior—adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly constructed sentence that conveys the core action and a critical qualifier. There is no fluff, redundant phrasing, or unnecessary detail—every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple tool with no output schema, but the description—combined with well-documented parameters—sufficiently covers the operation's essence. The only minor gap is not mentioning return behavior, but given the low complexity and absence of an output schema, the description feels complete enough for an agent to understand what will happen.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, meaning all six parameters are already described in the input schema (e.g., 'sceneItemId' as 'Numeric ID of the scene item'). The description does not add extra parameter-level detail beyond what the schema provides. The baseline of 3 applies because the schema handles parameter documentation, and the description adds no additional parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource pair ('Duplicate a scene item') and adds the meaningful qualifier 'while preserving its transform and crop,' which clarifies the operation's key behavior. This differentiates it from sibling tools like creating, removing, or transforming scene items, 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by describing the duplication action, but it does not explicitly state when to use this tool over alternatives (e.g., 'create-scene-item' or 'set-scene-item-transform'). No exclusions or alternative recommendations are provided, 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds no behavioral details beyond what annotations provide, but with such simple annotations and a simple read operation, the burden is already met. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence that is front-loaded and wastes zero words. It is concise and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, has no parameters, and is fully described by the one-liner. The annotations cover the read-only nature. There is no output schema, but for a 'get all' list, the description is adequate. A slightly more detailed description of what 'canvases' means could push it to 5, but overall it is fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, and schema coverage is 100% automatically. The description doesn't need to explain parameters because there are none, so this is a baseline 3. No additional parameter semantics are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Get all canvases available in OBS.' It clearly states the action (Get), the resource (canvases), and the scope (all available in OBS). It distinguishes itself from the sibling tool 'obs-get-scene-list' by using 'canvases' instead of 'scenes', indicating a different concept.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description 'Get all canvases available in OBS' simply states the function. It doesn't explicitly say when to use it versus alternatives, but the purpose is straightforward and the tool name is self-explanatory. There's no mention of when not to use it, but given the simplicity, a score of 3 is appropriate.
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?
Annotations already indicate read-only, non-destructive, and idempotent behavior, so the description's minimal text is acceptable. It adds clarity that it returns all groups, which is beyond the annotations. No contradiction, but it does not detail what is returned (e.g., list format), but given the simplicity, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of a single sentence with no wasted words. It is appropriately short for a simple tool with no parameters, achieving high clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool is simple, has no parameters, no output schema, and annotations cover safety aspects, the description is nearly complete. However, it could mention that it returns a list of group names or IDs, but this is not critical for a listing tool with no parameters. The completeness is adequate but not outstanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema description coverage is 100% (empty schema). The description does not need to explain parameters. Baseline for zero params is 4, and the description is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get all OBS groups' clearly states the action (get) and the resource (OBS groups), indicating a retrieval operation. However, it does not differentiate from similar sibling tools like 'obs-get-scene-list' or 'obs-get-scene-list', but the purpose is clear enough for selecting the 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/5
Does 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, but the name and description imply it is for listing groups. Given the large sibling set, there is no guidance on when to use it over 'obs-get-scene-list' or others, but the clear purpose provides implicit 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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is known. The description adds that it returns an array, which is implied by the name, but provides no additional behavioral context (e.g., ordering, pagination, or return details).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded and free of unnecessary details. It conveys the purpose efficiently with zero fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one optional boolean parameter and no output schema, the description is adequately complete. It could explain the meaning of 'unversioned' further, but the schema already provides that. No significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the single parameter 'unversioned' with a description (100% coverage). The tool description does not add extra meaning beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('gets an array') and the resource ('all available input kinds in OBS'). It is specific and distinguishes itself from sibling tools like obs-get-filter-kind-list and obs-get-transition-kind-list, which are for different 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies straightforward use: to list input kinds. However, it does not explicitly mention when to prefer this over similar listing tools, nor does it exclude use cases. Guidance is minimal but not misleading.
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?
Annotations already establish read-only, idempotent, non-destructive behavior. The description adds the return type ('array'), which is useful, but provides no additional behavioral context such as ordering, pagination, or effect of the optional filter. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundancy or filler. It conveys the essential purpose immediately and earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, read-only list operation with one fully documented optional parameter, the description plus schema is nearly complete. The return value is stated as an array, and no output schema is required to understand the high-level behavior. It could be slightly stronger with explicit guidance on when to prefer this over related list tools, but that is not essential.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single optional parameter inputKind is fully documented in the schema, so schema coverage is 100%. The description itself does not add parameter-level meaning, but the schema already carries that burden completely.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb ('Gets') plus resource ('array of all inputs in OBS'), clearly defining the tool's scope. It is distinct from sibling list tools like obs-get-input-kind-list and obs-get-special-inputs. The one-sentence description avoids tautology and matches the title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when you need a complete list of OBS inputs, and the optional inputKind filter is available in the schema. However, it does not explicitly state when to choose this over sibling tools such as obs-get-input-settings or obs-get-special-inputs, nor provide 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds no additional behavioral context, such as return format, error handling, or side effects. Since the annotations provide the core transparency, a neutral score of 3 is appropriate; the description is consistent but contributes nothing beyond the structured data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise and front-loaded with the main action. It contains no filler or redundant phrasing, earning the highest score for efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (no parameters, no output schema, simple read-only operation), the description is sufficiently complete. It states exactly what is retrieved. While it does not specify the filename format or behavior when no replay buffer exists, this is minor given the tool's simplicity and annotation coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema description coverage is 100% (vacuously). Per the rubric, 0 parameters warrant a baseline of 4. The description does not need to explain any parameters, and no additional parameter semantics are required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Gets the filename of the last replay buffer save file.' It uses a specific verb ('gets') and resource ('filename of the last replay buffer save file'), and it distinguishes itself from sibling tools like obs-get-replay-buffer-status (status) and obs-save-replay-buffer (saving) by focusing specifically on retrieving the filename.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention when not to use it, prerequisites, or mention other tools that might be more appropriate. The usage context is implied only by the tool's name and purpose, which is insufficient per the rubric.
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?
Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds the return type (array), which is consistent and provides slight additional clarity. No behavioral gaps are apparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that conveys the essential purpose without unnecessary detail. It is well-structured and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is sufficient for a simple getter, but it lacks detail about the structure of the returned array (e.g., names, objects). Given the absence of an output schema, a bit more specificity would enhance completeness, though it remains adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the schema fully covers the input. The description adds no parameter information, which is acceptable since there are none. Baseline score applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: it retrieves an array of all profiles. This is specific and distinguishable from sibling tools that list other entities like inputs or scene collections.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as when to fetch the current profile or set a profile. It lacks explicit usage context or comparisons to other profile-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?
Annotations already declare readOnlyHint=true and destructiveHint=false, informing the agent this is a safe read operation. The description adds only that it retrieves transform components, providing minimal extra behavioral context. It does not describe the return format (e.g., whether it returns a single object with all properties) or any potential errors, but the annotations cover the key safety aspects, so the description meets a baseline level.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with zero redundancy. It front-loads the action and target, making it immediately understandable. No unnecessary words or details are included, achieving perfect conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is a read-only getter with fully documented parameters and safe-operation annotations, the description is largely sufficient. The only gap is that it doesn't explicitly state that it returns all four transform properties together, which could be inferred but would help clarify the return value. Since no output schema exists, a brief note on the return structure would be beneficial but is not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, meaning each parameter has a clear description in the input schema. The tool description adds no additional parameter semantics—it doesn't clarify preferred identifiers or relationships between sceneName, sceneUuid, and canvasUuid. Since the schema already handles parameter documentation, a score of 3 is the appropriate baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: retrieving position, rotation, scale, or crop of a scene item. It uses a specific verb ('get') and identifies the resource ('scene item transform'), distinguishing it from other scene-item getters (e.g., enabled, index, locked) which handle different properties. The phrase 'or' might imply a choice, but it broadly covers the transform components, making the intent unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit when-to-use or alternative guidance. However, the purpose is self-evident: it's a read operation for transform data, and no competing getter exists for the same property. The absence of exclusions or mentions of when not to use it is acceptable given the simplicity, but it could be improved by noting that scene identifier parameters are optional or that a scene must be specified in practice.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering safety. The description adds no additional behavioral details (e.g., return format, null behavior if no override). It doesn't contradict annotations, but also doesn't provide extra context beyond what annotations already convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that states exactly what the tool does with zero redundancy. Every word adds value, and it's immediately graspable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with excellent annotations, a well-documented schema, and no output schema, the description is sufficient. It doesn't explain what the returned value contains (e.g., transition name) or edge cases like missing override, but that's not critical given the tool's simplicity and the annotation coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter (sceneName, sceneUuid, canvasUuid) having a clear description. The tool description adds no extra meaning beyond what the schema already documents. Baseline for high coverage is 3, and there's no additional clarification needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the specific resource ('the transition override configured for a scene'). It's unambiguous and distinguishes from the sibling setter (obs-set-scene-transition-override) and other transition tools like obs-get-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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The purpose implies it's for retrieving a scene override, but no exclusions or alternative mentioning is provided. The context of being a getter and having a setter sibling makes usage inferable, but the description itself offers no 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?
The description is consistent with the annotations (readOnlyHint=true, idempotentHint=true), but adds no additional behavioral context beyond what the annotations already declare. It doesn't describe return format or whether it errors when not streaming.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single declarative sentence, directly front-loaded with the action and resource. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter status getter with read-only annotations, this description is largely sufficient. However, it doesn't hint at the output structure (e.g., boolean vs. status object), which would require a small addition for full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema fully covers the input. The description adds no parameter semantics, but none are needed. Baseline 4 for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' with the resource 'streaming status', making the tool's purpose immediately clear. It distinguishes it from sibling status tools like obs-get-record-status or obs-get-virtual-cam-status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool over alternatives. There is no mention of checking before attempting to start/stop streaming, or that it is a read-only complement to control 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?
The annotations already declare readOnlyHint and idempotentHint, covering the safety and side-effect profile. The description adds no extra behavioral details, but it does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that fully conveys the tool's purpose without any extraneous words. It is perfectly sized for the simple action it describes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no parameters, the description sufficiently explains what the tool does. It does not mention return format, but that is not required since no output schema is present. The description is complete for its trivial nature.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters and the schema coverage is 100%, so there is nothing to explain. The description provides no additional parameter-related value, which is acceptable given the absence of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool gets whether studio mode is enabled. It is specific to studio mode, distinguishing it from other getter tools like obs-get-scene-list or obs-get-status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives, but as a getter for studio mode status, its intended use is implied. No additional guidance is provided for conditions 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds no further behavioral context (e.g., what settings are returned or any side effects). It does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler or unnecessary information. 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/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description should clarify what 'video settings' includes (e.g., resolution, FPS, etc.) to help the agent understand what is returned. The current description is too vague and does not enhance comprehension beyond the tool name. For a getter that returns a structured set of settings, it leaves the agent without adequate context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and 100% schema coverage (empty schema). The description does not need to explain parameter behavior. Baseline is 4 when there are no params, and the description adds nothing that could be misleading.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Gets the current video settings' uses a specific verb ('Gets') and targets a specific resource ('video settings'). It clearly distinguishes from the sibling tool obs-set-video-settings, which mutates those settings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the getter/setter relationship with obs-set-video-settings, but the description does not explicitly state when to use this tool versus alternatives or any exclusions. It provides no direct guidance on when to retrieve settings or how it fits into a workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish that this is not read-only, not idempotent, and not destructive. The description adds minimal behavioral context beyond restating the tool's function. It does not mention edge-case behavior like out-of-range offsets or whether media must be playing, but this is a simple operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no redundant words. It is precisely front-loaded and every word is meaningful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter mutation with no output schema and full schema coverage, the description is adequately complete. It could be improved by mentioning that the offset is relative and contrasting with the absolute setter, but the overall context is sufficient for a simple operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides a 100% description coverage for both parameters ('Name of the media input' and 'Value to offset the current cursor position by (in milliseconds)'). The description adds no further semantic detail beyond what the schema already contains, so baseline score 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Offsets') with a clear resource ('current cursor position of a media input'). It clearly distinguishes from the sibling 'obs-set-media-input-cursor' by indicating a relative adjustment rather than an absolute set.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the verb 'offsets', suggesting relative position changes, but there is no explicit guidance on when to use this tool versus 'obs-set-media-input-cursor' or other media input tools. 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not add behavioral context beyond what annotations already provide. It simply states the action. No mention of irreversibility, effects on scene items, or error conditions. Since annotations already declare destructiveHint=true and idempotentHint=true, the description adds no extra context, but it doesn't contradict either.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, directly stating the purpose without unnecessary details. It is front-loaded with the action and good for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter delete operation with no output schema, the description, combined with the schema and annotations, is mostly complete. It lacks context about potential failure modes or prerequisites, but the operation is straightforward. A score of 4 reflects that it's adequate but could mention if the input needs to exist or if removal cascades to scene items.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the parameter 'inputName' is fully described in the schema ('Name of the input to remove'). The description does not add any additional meaning or examples. Baseline is 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Removes an existing input' clearly identifies the action (remove) and the resource (input). It distinguishes from siblings like obs-create-input and obs-set-input-name by specifying the remove operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It implies usage from the action, but doesn't mention any use cases or exclusions. For example, it doesn't contrast with obs-remove-source-filter or obs-remove-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?
Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=true. The description 'Remove' aligns with these flags without contradiction. However, it adds no extra context about side effects (e.g., whether the underlying source is also deleted or if the action is reversible). Given the annotations cover the destructive nature, the description meets the baseline but does not enrich beyond 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that conveys the exact action without unnecessary verbosity. It is efficiently front-loaded and contains zero filler, earning a perfect score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple destructive operation with full schema documentation and no output schema, the description is adequately complete. It informs the agent of the core action and pairs well with the annotations. Minor missing context (e.g., relationship to source) is not essential given the tool's simplicity, so only a slight deduction from perfect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all four parameters (sceneName, sceneUuid, canvasUuid, sceneItemId) have descriptive comments in the schema. The description does not add any further parameter detail, which is acceptable given the high coverage and simple semantics. The baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Remove a scene item from a scene' uses a clear verb+resource structure, precisely stating the action (remove) and the target (scene item within a scene). It distinguishes well from siblings like obs-remove-scene (removes whole scene) and obs-create-scene-item, making 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (removing an item from a scene) but does not explicitly state when to prefer this over alternatives, such as obs-remove-scene for deleting an entire scene or obs-toggle-scene-item-enabled for toggling visibility. No exclusionary guidance is given, but the context is clean enough for a straightforward 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?
Annotations already convey the safety profile (idempotent, non-destructive), so the description does not need to repeat it. However, it adds no extra behavioral context such as what happens if transitionName is invalid or whether it affects current triggers.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It successfully states the tool's purpose without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple one-parameter setter with good annotations and no output schema, the description covers the core operation adequately. It omits minor details like requiring a valid existing transition name, but overall it is sufficient for agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter transitionName is already fully described in the schema. The tool description repeats the function name without adding semantics beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource ('Set the current transition in OBS') that clearly names the action. It also distinguishes itself from related siblings such as obs-get-current-transition and obs-trigger-transition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied by the operation name, but the description provides no explicit guidance about when to use it versus alternatives, nor does it mention that transitionName should reference an existing transition from obs-get-transition-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?
Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds no additional behavioral context beyond what annotations and schema descriptions provide, such as side effects 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no filler, front-loading the action verb and stating the object clearly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter setter with idempotent and destructive annotations and full schema coverage, the description is sufficiently complete. It could optionally mention that the input must exist, but that's covered by error handling and not essential for usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover both parameters (inputName and inputMuted) with clear meaning. The description adds no extra parameter-level information; with 100% schema coverage, the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Sets' and identifies the resource as 'the audio mute state of an input', clearly distinguishing it from sibling tools like obs-get-input-mute and obs-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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states the tool's function but provides no explicit guidance on when to use it versus alternatives such as obs-toggle-input-mute or obs-get-input-mute. Usage context is implied but not spelled out, so the agent must infer that this tool is for setting a specific mute state.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey that this is a mutating (readOnlyHint=false), non-destructive (destructiveHint=false), idempotent operation. The description adds no extra behavioral context such as error conditions or uniqueness constraints, but it does not contradict the annotations. With annotations present, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single complete sentence that states exactly what the tool does with no filler, repetition, or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a low-complexity tool with full parameter documentation and useful annotations. The description is sufficient for a simple rename operation, though it could optionally mention behavior when the input name does not exist or if the new name is invalid.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and both parameters are clearly described as 'Current input name' and 'New name for the input'. The description itself adds no additional parameter semantics, but the schema carries the full burden adequately, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Sets the name of an input (rename)'. This clearly distinguishes it from sibling rename tools like obs-set-scene-name or obs-set-source-filter-name by explicitly targeting inputs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: use this tool when you want to rename an input. However, it does not explicitly state when not to use it or mention alternatives such as obs-set-input-settings, so guidance is only implied rather than stated.
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?
Annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=true, covering the mutation safety profile. The description adds no extra behavioral context beyond repeating the action, such as permission requirements or effects on other parameters; it neither contradicts nor enriches the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, direct sentence with no fluff. It is front-loaded with the verb and resource, efficiently conveying the core operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with high schema coverage and annotations, the description adequately conveys the purpose. It could mention explicit alternatives or conditions (like 'use obs-get-profile-parameter to read'), but given the simplicity and structured context, it is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each of the three parameters having a clear description (including the null-for-delete semantics on parameterValue). The tool description adds no additional parameter meaning beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Sets) and the specific resource (a parameter in the current profile's configuration). It distinguishes from sibling tools like obs-get-profile-parameter and other set tools by referencing 'profile's configuration' precisely.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by its action and resource, but does not explicitly state when to use it versus alternatives (e.g., when to use obs-get-profile-parameter or other setter tools). No exclusions or alternative tool references are provided, leaving the agent to infer 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reiterates that it performs a set/rename operation, consistent with annotations (readOnlyHint=false). However, it adds no extra behavioral context such as error conditions, side effects, or permissions beyond what the annotations already convey. It does not contradict annotations, but the description does not contribute 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is extremely concise and to the point. It uses minimal words to convey the action without any fluff or redundant information. Every word earns its place, making it an excellent model of brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (a straightforward rename operation), the description is adequate. The schema fully documents parameters, annotations cover safety profile, and no output schema exists. The description covers the essential purpose; any additional detail (e.g., error handling) would be nice but is not necessary for this low-complexity operation. It is complete enough for an agent to correctly invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and each parameter already has a clear description in the schema (e.g., 'Current name of the filter', 'New name for the filter'). The description does not add any further meaning or clarify relationships between parameters. Since schema already covers semantics, 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (Sets) and resource (name of a source filter) and explicitly notes the action is to rename. It distinguishes from sibling tools like obs-set-source-filter-settings and obs-remove-source-filter by focusing solely on the name attribute. The purpose is unmistakable and specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when a filter needs to be renamed, but it does not explicitly contrast with alternatives or state when not to use it. No mention of related tools or preconditions, but the tool name itself makes the intended usage obvious, so 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?
Annotations already declare idempotentHint=true and destructiveHint=false, and the description does not contradict these. The description adds the "current transition" scoping, which is useful, but it omits any detail about whether the change takes effect immediately, affects in-progress transitions, or requires a transition to be active. With annotations present, the added behavioral context 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with zero filler. It states the action, target, and unit efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter setter with no output schema, the description covers the essential information: what is set, on what (current transition), and in what unit. It could be improved by noting whether a current transition must already exist, but this is a minor gap given the tool's simplicity and the idempotent annotation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the duration parameter already documented as "The duration to set in milliseconds." The description adds no additional parameter semantics beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb "Set" with a clear resource: "the duration of the current transition." It distinguishes itself from sibling tools like obs-get-transition-duration (get vs set) and obs-set-transition-settings (which handles broader settings). Units are also specified (milliseconds).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it (when you want to change the current transition's duration) but does not explicitly state prerequisites, such as having a current transition set via obs-set-current-transition, or when to prefer obs-set-transition-settings instead. No explicit alternatives or exclusions are mentioned.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds minimal behavioral context (e.g., 'current status' implies a snapshot). Since annotations are strong, a 3 is appropriate as the description does not contradict them and adds slight value beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that fully conveys the purpose without redundancy. It is appropriately sized for a zero-parameter, read-only status tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no params, no output schema, strong annotations), the description is complete enough. It tells the user what it reports (server status and connection). One could argue it might mention whether it checks both server and OBS application health, but 'server and OBS connection' is sufficiently broad.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema description coverage is 100% (effectively no params to describe). With no parameters, the baseline is 4, and the description correctly does not add parameter information because none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get the current status of the OBS MCP server and OBS connection' clearly states the verb (get), resource (status of OBS MCP server and OBS connection), and scope (current status). It distinguishes from sibling tools like obs-test-connection and obs-get-stats, though it doesn't explicitly name them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is a lightweight health check for the server connection, useful for verifying connectivity before other operations. However, it does not explicitly state when not to use it versus alternatives like obs-test-connection or obs-get-version, so there is room for clearer differentiation.
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 annotations already indicate read-only, idempotent, non-destructive behavior. The description does not add any extra context about side effects or behavior, but it is consistent with the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence, directly stating the purpose with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple getter, but it does not specify the exact format of the returned list (e.g., names vs. IDs). However, given the low complexity and presence of annotations, it is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes no parameters, so there are no parameter details to describe. The description is neutral on this aspect.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool retrieves a list of available transitions in OBS, which is specific and distinct from other tools like get-current-transition 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool over alternatives, such as get-transition-kind-list or get-current-transition. It simply states what it does without 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?
Annotations already provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds no additional behavioral context beyond the obvious (it gets status), but does not contradict annotations. It is acceptable but does not enrich the agent's understanding of return values or edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that precisely states the tool's purpose with no unnecessary words. It is appropriately sized and front-loaded, earning a top score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no params, no output schema) and that annotations cover safety, the description is minimally complete. However, it does not clarify what the status represents (e.g., boolean active/inactive) or any potential error conditions. A short note on return semantics would improve completeness, but it is not critically deficient for a trivial getter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is trivially 100%. Per the guidelines, 0 params baseline is 4. The description adds no parameter information because none exists, so it fully satisfies this dimension.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it gets the status of the virtualcam output, with a specific verb (Gets) and resource (status of the virtualcam output). This distinguishes it from sibling action tools like obs-start-virtual-cam and obs-stop-virtual-cam, and aligns with other status getters in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives, and does not mention any exclusions. However, the purpose is straightforward and implied by the name and description, so it meets the minimum viable level without misleading 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?
Annotations already indicate readOnlyHint=false, destructiveHint=false, and idempotentHint=true. The description does not contradict these and adds minimal behavioral context (e.g., what happens if already paused or not recording). It doesn't enrich beyond the annotations, which is acceptable for a simple action, but no extra insight is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It is appropriately sized for the tool's simplicity and delivers the core meaning immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters, no output schema, and a straightforward single-action behavior, the one-sentence description is complete enough for an agent to invoke the tool correctly. The context is low-complexity, so no further explanation is required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no schema detail to clarify. The baseline for zero parameters is 4, and the description doesn't need to explain any parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Pauses the record output' uses a specific verb and identifies the resource ('record output'). It clearly distinguishes itself from siblings like obs-resume-record and obs-toggle-record-pause, whose names and descriptions would imply opposite or combined 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool relative to alternatives, such as obs-toggle-record-pause or obs-resume-record. No exclusions, prerequisites, or context are given; the agent is left to infer usage solely from the name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate non-readonly and non-destructive, and idempotent. The description adds no extra behavioral details like effects on playback or 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single precise sentence with no redundancy or unnecessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While schema and annotations cover the basics, it lacks context on return behavior or side effects, but given the simple nature and full schema coverage, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema fully describes both parameters: inputName (name of input) and mediaCursor (new position in ms). No ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action (sets) and the target (cursor position of a media input). Distinct from sibling tools like offset by specifying 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this versus alternatives (e.g., offset), prerequisites, or error conditions. The one-line description lacks contextual usage direction.
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?
Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is known. The description adds a useful 'inspect first' behavioral safeguard and 'pinned protocol' context, but it does not elaborate on side effects, return behavior, or error cases. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the core action and the key prerequisite with no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a generic call-any tool, the description plus annotations and full schema coverage provide sufficient selection and invocation context: it identifies the protocol, instructs to inspect first, and the schema defines both parameters. No output schema exists, but the return value is inherently the OBS response; a bit more on fallback use vs dedicated tools would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameters are already described in the input schema. The description reinforces that requestData is defined by obs-describe-request and that requestType must be exact, but it adds little beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Call') and resource ('any request in the pinned OBS WebSocket protocol'), making the tool's generic purpose immediately clear. It also distinguishes itself from the many dedicated obs-* sibling tools by positioning itself as a catch-all request dispatcher.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The instruction to 'inspect it with obs-describe-request first' provides an explicit prerequisite and workflow guidance. However, it does not explicitly state when to prefer this generic tool over the dedicated sibling tools, nor does it list exclusions, so usage context is clear but not fully exhaustive.
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 beyond basic creation: the tool automatically switches to the new profile. This is a significant side effect. The annotations only indicate it is not read-only (readOnlyHint=false), so the description adds valuable context. However, it does not mention error conditions (e.g., duplicate names) or prerequisites, but for a simple creation mutation, the disclosure is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that efficiently communicates both the primary action and the side effect. There is zero redundancy, and the structure is front-loaded with the verb and resource. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter, no output schema, and clear annotations, the description is mostly complete. It covers the purpose and side effect, but could mention that the profile must have a unique name or that OBS must be running. However, given the simplicity and existing annotations, it is sufficiently complete for an agent to use it correctly without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage: the profileName parameter is documented as 'Name for the new profile'. The tool description adds no additional parameter insights, but since schema coverage is high, the baseline of 3 applies. The description does not need to reiterate the parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Creates a new profile' and includes a specific side effect, 'switching to it in the process'. This distinguishes it from sibling tools like obs-set-current-profile (which only switches) and obs-remove-profile. It uses a specific verb and resource, 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (create and switch) but does not explicitly contrast with alternatives or state when not to use it. No mention of 'use obs-set-current-profile if the profile already exists' etc. It provides context but lacks explicit exclusion or alternative guidance, which would improve decision-making among profile-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?
Annotations only indicate readOnly=false and do not provide much behavioral context. The description adds a valuable side-effect disclosure: creating the collection also switches to it. It does not cover edge cases like duplicate names, but for a simple creation tool the main behavioral trait is clearly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It states the action, the resource, and the important side effect in minimal words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity—one required parameter, no nested objects, no output schema—the description is nearly complete. It states the core action and the side effect. It could go slightly further by noting behavior on duplicate names or whether an error is returned, but that is not essential for basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
One parameter is documented in the schema with 100% coverage: sceneCollectionName is described as 'Name for the new scene collection.' The description adds no parameter-specific meaning, but because the schema fully covers the parameter, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Creates') and a clear resource ('scene collection'), plus the key behavioral detail that it switches to the new collection. This distinguishes it from sibling tools like obs-set-current-scene-collection, which switches to an existing collection, and obs-get-scene-collection-list, which lists collections.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied: use this tool when you need a new scene collection and want to switch to it immediately. However, there is no explicit guidance about when not to use it or which sibling alternative to choose, such as obs-set-current-scene-collection for switching to an existing collection.
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?
Annotations indicate non-read-only and non-destructive behavior, and the description aligns with that. However, the description does not elaborate on side effects, error conditions, or idempotency (annotations say idempotentHint: false). It could mention potential failures if the filter already exists or if the source is invalid, but overall provides basic transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that captures the essential action without redundancy. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for the tool's simple purpose. It does not require explanation of return values (no output schema) and the annotations cover mutability and idempotency hints. It might benefit from a note about prerequisites (e.g., source must exist), but that is implied and not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All parameters are described in the schema with clear, though minimal, explanations. For example, 'filterKind: The kind of filter to be created' and 'sourceName: Name of the source to add the filter to'. No examples or constraints (e.g., valid filter kinds) are provided, limiting depth, but the descriptions add context beyond the parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (creates) and the resource (a filter) and the target (specified source). It distinguishes from sibling tools like obs-set-source-filter-settings or obs-remove-filter by explicitly mentioning creation and adding to a source.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes it clear when to use this tool (to create a new filter on a source), but does not explicitly state when not to use it or mention alternatives. However, the distinct purpose is evident from the name and description, so it's sufficient.
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?
Annotations already declare it read-only, idempotent, and non-destructive; the description adds context by noting the protocol is pinned and that the tool returns exact field/constraint specifications. It does not describe output shape or omitted-parameter behavior, but the annotation coverage lowers that burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with a precise verb and object, containing no filler or redundant wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple introspection tool with strong annotations and full schema coverage, the description sufficiently captures the tool's role. It could mention default behavior when no parameters are supplied or expected output shape, but it is still complete enough for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and both parameters are already clearly documented in the schema; the description itself adds no extra parameter semantics, so the baseline score applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Inspect') and a clear object ('exact fields and constraints of requests in the pinned OBS WebSocket protocol'), making the tool's function obvious and distinguishing it from the many sibling OBS action 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It implies use when you need request field details or constraints, but it never explicitly explains when to use this tool instead of alternatives such as obs-call-request, nor does it describe workflow fit or 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?
The annotations already declare readOnlyHint=true and idempotentHint=true, covering safety. The description adds no further behavioral context, such as what happens if the input is invalid or how the response is structured. Since the bar is lower with annotations, a 3 is appropriate for minimal added value beyond the structured declarations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no redundant words. It states the action and target efficiently, making it easy for an agent to grasp the tool's purpose quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no output schema, the description is adequate. It clearly states what is retrieved, and the annotations handle safety. It might benefit from noting the return format (e.g., list of track numbers), but given the low complexity and full parameter schema coverage, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters (inputName and inputUuid) are fully described in the schema (100% coverage). The description adds no additional parameter semantics, such as whether either parameter is required or how they interact. The baseline of 3 for high schema coverage applies, and the description does not compensate further.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the specific resource 'enabled audio tracks for an input', distinguishing it from sibling tools like obs-set-input-audio-tracks. It precisely identifies what is retrieved without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use it (to retrieve the enabled audio tracks of an input) but does not explicitly mention alternatives or exclusions. It is straightforward for a getter, and its purpose stands out among sibling read/write tools, though it could name the setter as an alternative.
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 annotations already indicate read-only, idempotent, and non-destructive behavior, and the description adds no additional details about side effects, errors, or limitations, so it does not go beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is direct and front-loaded with the verb, containing no unnecessary words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description gives a clear indication of what the tool returns (selectable items) and the context (dynamic input list property), which is sufficient for a simple getter, though it does not specify the exact return format or any edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already includes descriptions for all three parameters (inputName, inputUuid, propertyName), and the description does not add any further clarification or context for these parameters, so it adds no value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the resource ('selectable items for a dynamic input list property'), making it distinct from sibling tools that handle other input properties or different object 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context by specifying 'dynamic input list property', which helps an agent understand when to use it, but it does not explicitly mention alternatives or situations where this tool should not be used.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description adds no costly behavioral details. The word 'available' hints at the result set but does not specify whether it includes all outputs or only active ones. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. Every word contributes to the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple list getter with no parameters and strong annotations. The description is sufficient for selecting and invoking it, though it does not describe the exact response format. Given the low complexity, this is adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so there is nothing to document. According to the rubric, 0 params yields a baseline of 4. The description correctly avoids inventing parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states a specific verb ('Gets') and resource ('list of available outputs'), clearly distinguishing it from sibling tools such as obs-get-output-status and obs-get-output-settings. The word 'list' indicates the return type and scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit usage guidance is provided, but the action is self-evident: call when you need the list of outputs. This falls under implied usage rather than explicit alternatives or 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?
Annotations already declare readOnly/idempotent/non-destructive; the description consistently states 'Gets' and adds the 'current profile' scope. No information about return value or error handling is provided, but annotations lower the bar.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded, no filler. Concisely states the function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with full schema coverage and safety annotations, the description along with schema is self-sufficient. It lacks details on return format or absence behavior, but such a simple tool benefits from brevity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes both parameters with clear explanations ('Name of the parameter to get', 'Category of the parameter to get'). The description adds no additional parameter semantics; schema coverage is 100%, so baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Gets') and the target resource ('a parameter from the current profile's configuration'). It is distinct from sibling setter tools like obs-set-profile-parameter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving a configuration parameter from the current profile. It provides clear context but does not explicitly mention alternatives or when not to use it. The sibling setter is obvious but not referenced.
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?
Annotations already declare readOnly, idempotent, non-destructive; description adds no extra behavioral context, but does not contradict.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One concise sentence with no redundancy; perfectly sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, so return details are not required; description adequately conveys the tool's purpose without needing further context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is complete; description does not need to elaborate, baseline for zero params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb 'Gets' and resource 'array of all scene collections', distinguishing it from sibling tools that get other resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Does not explicitly state when to use this tool over alternatives, though the purpose is clear from the name and description; lacks guidance on scenarios or exclusions.
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 annotations already indicate read-only and idempotent behavior, and the description ('Get') is consistent with these traits. It does not add extra behavioral context beyond the annotations, but no contradictions exist, and the annotations sufficiently cover safe usage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that directly states the function. It is appropriately sized and front-loaded, with no unnecessary words or complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter, the description is sufficient to convey the core functionality. It does not specify the return type (boolean) or error conditions, but given the simplicity and the presence of annotations, it is adequately complete for most use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides descriptions for all parameters, and the tool description does not add additional meaning about how to use them, such as whether a scene identifier is necessary alongside the item ID. Since schema coverage is 100%, the baseline is 3, and no extra context is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the locked status of a scene item, using a specific verb and resource. It distinguishes itself from other scene item getters like 'get scene item enabled' or 'get scene item index' by focusing solely on the locked property.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives, such as checking lock status before modifying an item. It only implies usage when the locked state is needed, without discussing exclusions or alternative 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description doesn't need to repeat safety. However, it adds no extra behavioral detail—such as how missing scenes are handled, whether results are unordered, or if there are pagination limits. It is consistent with annotations but does not enhance them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that is front-loaded with the core purpose. No filler or redundant phrases; every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list operation with no output schema, the description communicates the primary function clearly. It does omit guidance on parameter selection (e.g., whether sceneName and sceneUuid are mutually exclusive), but given the simplicity and strong annotations, the description is adequately complete. A 4 is appropriate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each property (sceneName, sceneUuid, canvasUuid) having a clear description. The tool description adds no additional meaning beyond what the schema provides, nor does it clarify whether parameters are alternatives or how they interact. Baseline 3 is appropriate given full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get a list of all scene items in a scene' uses a specific verb ('Get'), names the resource ('scene items'), and specifies the scope ('in a scene'). It clearly distinguishes from sibling tools like obs-get-group-scene-items (which targets a group, not a scene) and obs-get-scene-item-enabled (which returns a specific state). 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use this tool: when you need the complete list of scene items for a scene. It does not explicitly mention alternatives or exclusions (e.g., 'use obs-get-group-scene-items for group items'), but the name and phrasing strongly imply its scope. This meets the 'clear context, no exclusions' criterion.
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?
Annotations already declare readOnlyHint=true and idempotentHint=true, so safety is covered. The description adds the behavioral detail that the screenshot is returned as a Base64-encoded string, which is valuable for understanding the return value. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the core action and return format. Zero wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only screenshot tool with full schema and annotations, the description is sufficient. It states the return format (Base64) and identifies the resource, which is enough given the schema covers parameters and annotations cover safety.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers all 7 parameters with descriptions, so the baseline is 3. The description itself adds no additional parameter-level detail beyond identifying the resource as a source, but it doesn't need to since the schema is complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets a Base64-encoded screenshot of a source, specifying the verb 'gets' and the resource. It distinguishes itself from the sibling obs-save-source-screenshot, which saves to a file, 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
While the purpose is clear, there is no explicit guidance on when to use this tool versus alternatives like obs-save-source-screenshot or when to avoid it. The usage context is implied by the get/save distinction but not explicitly 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?
The description adds no behavioral information beyond what annotations already convey (readOnlyHint=true, idempotentHint=true, destructiveHint=false). It merely restates that the tool 'gets' settings, which is redundant with the readOnlyHint. No additional context is provided about return format, side effects, or conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the action, and contains no unnecessary words. It is appropriately concise for a simple, no-parameter getter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no parameters and no output schema, the description adequately conveys that the tool returns the current stream service settings. However, it does not elaborate on the nature or format of those settings, which would be helpful for an agent expecting to parse the response. Overall, it is mostly complete but lacks minor detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is 100%, so the baseline is 4. The description does not need to compensate for missing parameter information, as there are no parameters to describe. The description correctly implies no inputs are required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Gets the current stream service settings' uses a specific verb (Gets) and resource (stream service settings), clearly distinguishing it from sibling tools like obs-set-stream-service-settings and other getters. It is unambiguous and fully identifies 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: use this tool when you need to read or retrieve the current stream service settings. The get/set distinction with the sibling tool provides clear context, though it does not explicitly state exclusions or alternatives. No explicit when-not-to-use guidance exists, but the context is sufficient.
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?
Annotations already indicate readOnlyHint=false, destructiveHint=false, and idempotentHint=true. The description adds no additional behavioral context (e.g., what happens if not currently streaming, or side effects). It does not contradict annotations, but it also does not enhance them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no unnecessary words. It is perfectly concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, idempotent stop action, the description is adequate. It could mention the difference from obs-toggle-stream, but that is not strictly necessary given the simple nature of the tool and sufficient annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters and schema coverage is 100%, so the schema provides no ambiguity. The description needs no parameter explanation; a baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Stop streaming in OBS' clearly specifies the action (stop) and the resource (streaming in OBS), and it is distinct from sibling tools like obs-start-stream and obs-toggle-stream.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives like obs-toggle-stream. The intended use is implied by the name, but no guidance is given on conditions (e.g., only when streaming is active).
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?
Annotations already convey it's a write operation (readOnlyHint=false) and not destructive. The description adds value by specifying the event type (CustomEvent) and the destination (all WebSocket clients), which goes beyond what annotations provide. No contradictions; it's consistent with the non-read-only nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that immediately states the verb and target. No wasted words, and the key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple broadcast tool with one parameter and no output schema, the description is sufficient. The schema fully defines the interface, and the tool's behavior is clear without needing further elaboration on return values or complex side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter eventData, which is explained as 'Data payload to emit to all receivers'. The description adds no extra parameter info, but given full schema coverage, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (broadcasts), the resource (a CustomEvent), and the target (all WebSocket clients). It distinguishes from sibling tools like obs-send-stream-caption, which targets captions specifically, making it unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternatives are provided, but the purpose is specific enough that an agent can infer it's for sending custom events to clients. There are no competing tools in the sibling list, so minimal guidance is acceptable, though explicit context (e.g., 'use this to emit arbitrary events to connected clients') would improve the score.
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 states the tool 'gets whether a scene item is enabled', making the read-only behavior clear. The readOnlyHint annotation aligns with this. However, it does not mention possible side effects or the exact response structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence, which is perfectly concise for a simple getter. The schema is structured clearly with properties and types.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks context about OBS scene items retrictions (e.g., whether sceneName or sceneUuid is needed, or how to obtain sceneItemId). While the sibling tools provide some context, the description itself is incomplete for a user unfamiliar with OBS API.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Each parameter has a concise description: sceneName as string, sceneUuid as string, canvasUuid as string, and sceneItemId as integer. The required field is clearly indicated. Yet, the descriptions are terse and do not explain relationships or priority among the identifiers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The tool name and description clearly indicate that it retrieves the enabled status of a scene item in OBS. The purpose is unambiguous and directly stated without extra jargon.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description is minimal and does not explain how to specify the scene item (e.g., which identifier to use). While the schema indicates sceneItemId is required, it does not clarify when sceneName, sceneUuid, or canvasUuid should be provided, potentially leaving users uncertain.
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?
Annotations already declare destructiveHint and idempotentHint, so the safety profile is known. The description adds value by disclosing that selecting the current profile triggers an automatic switch to another profile first, a non-obvious behavior. This extra context goes beyond the annotations and is essential for safe 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that packs the core action and a crucial edge case. There is zero filler, and every word earns its place. It is optimally concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter destructive tool with clear annotations, the description covers the essential action, the special behavior when removing the current profile, and does not need to elaborate on return values (no output schema). It is complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description fully covers the only parameter 'profileName' with 'Name of the profile to remove'. The tool description does not add additional meaning or constraints beyond that. Given the 100% schema coverage, the baseline score of 3 is appropriate; the description contributes nothing new param-wise.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Removes a profile', using a specific verb and resource. It distinguishes from sibling profile tools like obs-create-profile and obs-set-current-profile by specifying the removal intent. The added note about switching profiles if the current one is selected further clarifies the exact scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for removing profiles but does not explicitly compare with alternatives or state when not to use. The side-effect note about current profiles provides some contextual guidance, but there is no clear 'use this instead of X' or exclusion criteria. This earns a middle 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?
Annotations already declare idempotentHint=true, destructiveHint=false, and readOnlyHint=false, which covers the safety profile. The description adds minimal context beyond 'enables/disables,' but it does not contradict annotations. It doesn't explain side effects (e.g., what happens to preview/scene) but that's beyond the tool's scope. With annotations present, the added value is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clutter-free sentence that directly captures the purpose. It is front-loaded and efficient, with zero wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with one boolean parameter and no output schema, the description is fully complete. It conveys the action and its parameter without ambiguity. There are no missing prerequisites or consequences to disclose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'studioModeEnabled' fully documented as a boolean for toggling. The tool description essentially repeats the schema's parameter description, adding no new meaning. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: it enables or disables studio mode. The verb 'enables or disables' is specific, and the resource 'studio mode' is unambiguous. It distinctly contrasts with sibling obs-get-studio-mode (which retrieves state), so it differentiates well.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear intent (set studio mode on/off). It doesn't explicitly mention when not to use it or alternatives, but given the simplicity and the existence of a getter sibling, the usage context is implicitly obvious. 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and idempotentHint=true, so the safe, non-mutating nature is established. The description adds that it can sleep by milliseconds or frames, giving concrete behavioral specifics beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One short, clear sentence with no redundancy; all words earn their place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, two optional parameters, solid schema descriptions, and annotations, this description is adequate. It explains the core behavior without needing to detail return values (none) or complex side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters are fully described in the schema (100% coverage), so the description doesn't need to add much. It does align the two units ('time duration' = sleepMillis, 'number of frames' = sleepFrames), but it doesn't clarify precedence or exclusivity, so it adds minimal value over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'sleeps' and specifies the resource ('a time duration or number of frames'), making it clear this is a wait/timing tool. It is distinct from the 150+ OBS sibling tools, none of which perform timing delays.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states what the tool does but gives no context for when to use it relative to alternatives, such as 'use this to insert a delay between OBS operations.' Since there are no sibling sleep tools, it is not actively misleading, but it lacks explicit usage 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?
The description adds minimal behavioral context beyond the annotations. idempotentHint=true is provided, and the description does not contradict it. However, it doesn't explain what happens if no recording is active or whether it also affects paused states.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, a single sentence that directly states the action. No wasted words, front-loaded with the verb.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple stop action with no parameters and annotations covering safety (idempotent, non-destructive), the description is fully sufficient. It clearly identifies the target as 'record output' and provides adequate context for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and the schema reflects that. The baseline for zero parameters is 4, and the description doesn't need to add parameter info. It correctly avoids unnecessary details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Stops the record output' uses a specific verb and resource, clearly indicating the action of stopping the recording. It distinguishes itself from sibling tools like obs-start-record and obs-toggle-record by naming the stop operation directly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. It is implied that it stops an ongoing recording, but nothing is said about using it when not recording or comparing it to toggle-record.
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?
Annotations already indicate readOnlyHint=false (write operation), destructiveHint=false (non-destructive), and idempotentHint=true. The description adds no extra behavioral context beyond restating the action. While it does not contradict annotations, it does not enhance them either, so it meets the baseline for a trivial tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no unnecessary words. It front-loads the core purpose and contains only the essential information. This is ideal conciseness, though it is minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and no output schema, the description fully covers what the tool does. Annotations provide the safety profile (idempotent, non-destructive). The context is simple enough that no further elaboration is needed, making the description complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so schema coverage is 100% by default. The description does not need to explain parameters, and the baseline for 0 parameters is 4. The description adds no additional information, but that is acceptable given there is nothing to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Stops the virtualcam output' uses a specific verb ('stops') and resource ('virtualcam output'), clearly identifying the action. It is distinct from sibling tools like obs-start-virtual-cam and obs-toggle-virtual-cam, which handle start and toggle operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (to stop the virtual camera) but does not explicitly mention alternatives or exclusions, such as noting that 'obs-toggle-virtual-cam' could be used interchangeably or that stopping is idempotent. With no explicit guidance, it is adequate but not strong.
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?
Annotations already indicate readOnlyHint=false, so the agent knows it's a write operation. The description adds minimal extra behavioral context beyond stating the purpose; it doesn't mention potential side effects, Idempotency, or state dependence, but these are not critical for a simple toggle. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. It is front-loaded and directly communicates the purpose without any filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema, clear purpose), the description is complete. Sibling tools provide sufficient context, and the description does not need to elaborate on return values or edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is trivially 100%. According to the rubric, a 0-parameter tool receives a baseline score of 4 for parameter semantics, as there is no need for the description to explain parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Toggles pause') and the resource ('the record output'), distinguishing it from sibling tools like obs-pause-record and obs-resume-record, which set a specific state rather than toggle. It also contrasts with obs-toggle-record which toggles recording, not pause.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives like obs-pause-record or obs-resume-record. The toggle nature is implied by the name but not stated, leaving the agent to infer that it is useful when the current pause state is unknown.
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?
Annotations already declare non-read-only and non-idempotent. The description adds 'toggles the state,' which is useful but minimally beyond what can be inferred from the name and annotations; it does not describe side effects or prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded, with no unnecessary words. It perfectly conveys the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple mutation tool with no parameters and no output schema, the description is complete. It tells the agent exactly what the tool does without missing critical information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the description appropriately does not list any. Per the baseline for parameterless tools, this is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the action (toggles) and the resource (virtualcam output), clearly distinguishing it from sibling tools like obs-start-virtual-cam and obs-stop-virtual-cam which are explicit start/stop actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this toggle vs the start/stop alternatives. The context implies it is for flipping the state, but the description does not state 'use this when you don't know the current state' or similar.
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?
Annotations already declare readOnlyHint and idempotentHint, so the description adds minimal behavioral context beyond aligning with the getter nature. It does not describe what happens if no directory is set, but given the annotations, this is 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, precise sentence with no wasted words. It front-loads the action and resource clearly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no parameters and no output schema, the description is adequate. It doesn't specify potential edge cases like default directory behavior, but the annotations and tool name provide sufficient context for expected usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is 100% (trivially). The description correctly does not attempt to explain parameters, and the baseline for 0-param tools is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (gets) and the resource (current directory for record output), making it distinct from the setter sibling (obs-set-record-directory) and other record-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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for reading the current record output directory, but it does not explicitly mention when not to use it or name alternative tools. However, given the tool's simplicity and clear getter nature, the context is clear enough.
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?
Annotations already indicate it's a non-read-only action (readOnlyHint=false) and non-idempotent. The description adds the preview-to-program context but doesn't disclose prerequisites (e.g., studio mode must be enabled) or error behavior, so it adds limited value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the action and context. Every word earns its place with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no parameters and no output schema, the description is adequate. It could mention that studio mode must be active or what happens if it's not, but it's not critical for this action's completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters (0), which is the baseline for parameter semantic scoring. Nothing needs explanation beyond the schema, so a score of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('trigger a transition') and the specific resource/context ('from preview to program scene in Studio Mode'), distinguishing it from the generic obs-trigger-transition tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context (Studio Mode) but does not explicitly mention when not to use it or name alternatives like the generic transition trigger. However, the context is sufficient for an agent to infer its use.
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?
Annotations already declare readOnlyHint=true and idempotentHint=true, covering safety. The description adds the behavioral detail that it returns the transition name, which is not in annotations. No contradictions, and the extra context about the return value is useful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, 11 words, front-loaded with the verb and object. 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.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no parameters, no output schema, and comprehensive annotations, the description fully covers the tool's purpose and expected behavior. It doesn't address edge cases (e.g., no active transition), but the simplicity and annotation coverage make it complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so schema coverage is 100% and the parameter semantics are trivially complete. Baseline for 0 params is 4; the description adds no parameter info, but none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the specific resource ('the name of the currently active transition'). It distinguishes from siblings like obs-get-transition-list (list all) and obs-set-current-transition (change) by specifying 'currently active' and returning the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (when you need the current transition name) but does not explicitly mention alternatives or when not to use it. Unlike better examples, it doesn't reference sibling tools or provide exclusion criteria.
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 annotations already declare readOnly, idempotent, and non-destructive behavior. The description is consistent with these by stating 'Gets an array', adding minimal context about the return type. No contradictions or hidden side effects are present, so transparency is well handled.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no superfluous words. It directly states the action and result, making it highly efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool and lack of output schema, the description adequately explains the return value as 'an array of all hotkey names'. It covers what is returned without needing to mention edge cases, making it complete for this context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so schema coverage is 100% by default. The description adds no parameter-specific information, which aligns with the baseline of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Gets', the resource 'array of all hotkey names', and the scope 'in OBS'. It is specific and distinguishes this tool from siblings that handle scenes, inputs, or other entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context that this tool is for retrieving hotkey names, and since there is no alternative for listing hotkeys among siblings, the usage is implicitly defined. It does not explicitly mention alternatives, but the purpose statement gives sufficient 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, fully covering the safety profile. The description adds no extra behavioral context beyond what annotations provide, which is acceptable for such a simple read-only operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that states exactly what the tool does without unnecessary detail. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and simple return value, the description is complete enough. The annotations cover safety, and no output schema is needed for such a straightforward operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema is empty. According to the rubric, a baseline of 4 is appropriate for no parameters, and 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get OBS Studio version information' uses a specific verb ('Get') and clearly identifies the resource (OBS Studio version information). It fully distinguishes this tool from sibling tools, as no other tool appears to fetch version info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
While no explicit when-to-use guidance is provided, the tool's purpose is self-evident: use it to retrieve the OBS version. Clear context with no exclusions or alternatives, given there is no sibling tool for version retrieval.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds the 'Studio Mode' condition, which is relevant behavior beyond the annotations. No contradictions, and no side effects are implied beyond the getter nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that conveys the purpose and context without any filler. It is front-loaded with the verb and resource, and every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and no output schema, the description is complete enough. It identifies the specific operation and meaningful domain (Studio Mode). Given the simplicity and strong annotations, no further explanation about return values is necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so per guidelines the baseline is 4. The description adds nothing about parameters, but none are needed; the schema is empty and fully documented by existing coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Get the current preview scene' with the specific scope 'in OBS Studio Mode'. This distinguishes it from sibling 'obs-get-current-scene' which likely returns the program scene, and it names the exact resource and context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage in Studio Mode, which is a key context, but does not explicitly compare to alternatives like 'obs-get-current-scene' or mention when not to use it. However, for a simple getter, the intent is clear and the mode mention provides sufficient context.
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?
The annotations already indicate readOnly, idempotent, and non-destructive behavior. The description adds no contradicting information and is fully consistent. Since it is a simple getter with no side effects, transparency is complete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly states the tool's function. No extraneous information, perfectly structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema), the description fully covers what the tool does and its return type. It is complete for the intended purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and the schema coverage is 100%. The baseline for zero parameters is 4 per the rubric, and the description adequately explains what the tool returns without needing parameter explanations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Gets) and the resource (array of all available source filter kinds), distinguishing it from similar getters like obs-get-input-kind-list and obs-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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
While it does not explicitly mention alternatives, the purpose is self-evident for a getter of filter kinds. The sibling tools context makes the usage clear enough, so it is adequate but not explicit about when to use vs alternatives.
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:

[![OBS-MCP MCP server](https://glama.ai/mcp/servers/Tom-R-Main/OBS-MCP/badges/card.svg)](https://glama.ai/mcp/servers/Tom-R-Main/OBS-MCP)

Score Badge

Copy to your README.md:

[![OBS-MCP MCP server](https://glama.ai/mcp/servers/Tom-R-Main/OBS-MCP/badges/score.svg)](https://glama.ai/mcp/servers/Tom-R-Main/OBS-MCP)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Tom-R-Main/OBS-MCP'

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