Sets the OBS T-Bar position between 0.0 and 1.0, with an optional release, so you can control manual transition progress.
Sets the position of the TBar
| Name | Required | Description | Default |
|---|---|---|---|
| release | No | Whether to release the TBar (default true) | |
| position | Yes | New position between 0.0 and 1.0 |
Changes observed during successful MCP inspections.
v1.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the full disclosure burden, and it discloses almost nothing. It does not state the studio-mode prerequisite, whether moving the TBar live affects program output, or that the `release` flag likely commits a transition – all critical side-effect information for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single short sentence that is front-loaded with the verb and resource, with zero padding. But the brevity comes at the cost of substance – it is under-specified rather than efficient, given the tool's stateful behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations, no output schema, and a stateful side-effect parameter (`release`), the definition is not complete enough. An agent could invoke it outside studio mode or inadvertently trigger a transition without warning.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (both `position` with its 0.0–1.0 range and `release` with its default true are documented in the schema), so the baseline of 3 applies. The description adds no meaning beyond the schema – notably it never explains what "release" does operationally or that position is a normalized fader value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
"Sets the position of the TBar" names a specific verb (sets) and a specific resource (TBar position), so it is not a tautology. However, "TBar" is undefined jargon – an agent unfamiliar with OBS studio mode has no way to know this refers to the studio-mode transition fader, and no sibling tool is referenced to anchor it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance at all: nothing says this requires studio mode to be active, nor how it relates to obs-trigger-studio-transition or obs-set-studio-mode, which are the obvious alternatives/companions. The agent must infer the 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.