obs-showrunner-mcp

by takurot

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools are clearly distinct by resource and action: start_show/end_show/switch_segment handle show flow, while set_scene/get_scene_list handle scenes, and show_overlay/hide_overlay handle overlays. The only mild ambiguity is between switch_segment and set_scene, and between trigger_effect and update_source_content, but the descriptions clarify their different purposes. Overall boundaries are distinct.
Naming Consistency5/5
The naming is highly consistent: nearly all tools use a clear verb_noun pattern (start_show, end_show, switch_segment, show_overlay, hide_overlay, get_scene_list, set_scene). All use snake_case with imperative verbs. The style is uniform and predictable throughout.
Tool Count4/5
18 tools for a show-runner MCP server feels appropriate given the breadth of capabilities it needs to cover: show lifecycle, OBS scene management, overlays, effects, health monitoring, and audio. Each tool serves a distinct function and none feel extraneous for the apparent scope of running live shows via OBS.
Completeness4/5
The tool set covers show lifecycle (start/end/segment), OBS scene control, overlays, audio, effects, and health/connection diagnostics. Gaps exist: no segment rollback or scene visibility controls, and no realtime state subscription mechanism, but the core show-running operations and OBS basics are covered. The inclusion of debugging utilities (get_debug_config, reconnect_obs) is a thoughtful addition, though there's no explicit 'stop' for effects or a way to revert sources.
Average 2.8/5 across 18 of 18 tools scored. Lowest: 1.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on January 5, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states only the action (hiding) without describing effects on subsequent overlays, whether the operation is reversible by show_overlay, persistence across sessions, or side effects on related segments. Very thin behavioral coverage for a mutating UI tool.
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 (one phrase), which is efficient, but this is under-specification rather than true conciseness. It front-loads the purpose but at the cost of any meaningful information. Borderline between a 2 and 3; the brevity is at least not bloated.
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?
With no annotations, no output schema, 0% schema description coverage, and a single undocumented parameter, this description is completely inadequate. Comparable to a similar tool hide (without the context of having 18 siblings to differentiate from), it provides almost nothing for an agent to correctly select and invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not mention overlayId at all. The single required parameter gets no added meaning—no guidance on how to obtain a valid overlayId, its format, or what values are valid. The description adds nothing beyond the raw schema.
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 'Hide an overlay' has a verb+resource but no detail about what kind of overlay, what hiding entails visually, or how this differs from the sibling tool show_overlay (presumably the inverse). It's minimally clear but lacks any specificity about scope or behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to hide an overlay, what state prerequisites exist (e.g., must the overlay be currently visible?), or how it relates to alternatives like switch_segment, show_overlay, or trigger_effect. The description provides zero usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It doesn't state whether this mutates state, whether it's a fire-and-forget transient effect, whether it requires an active connection, what side effects occur, or whether it interrupts/overrides other effects. The term 'effect' implies a transient display change but this is never made explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with no fluff. However, this leans toward under-specification rather than genuine conciseness—the brevity comes at the cost of substance. Still, on pure conciseness grounds it's clean and front-loads the verb.
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?
A 3-parameter tool with 0% schema coverage, no annotations, and no output schema is severely under-documented. For a tool with a required string parameter (effectType) that has no enum constraints, the agent cannot possibly invoke it correctly without guessing valid effect names. This is wholly inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for full documentation of the 3 parameters. It does nothing of the sort. effectType (a string with no enum values) is required but its valid values are undocumented; intensity and durationSec have no range, unit, or default semantics explained. The agent has no idea what values are valid.
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 'Trigger a visual effect' states an action (trigger) and resource (visual effect), but is extremely vague. It doesn't specify what kinds of visual effects exist, how this differs from related tools like show_overlay, hide_overlay, or switch_segment, or what the effect actually produces visually. Given the sibling set includes multiple display/overlay tools, there's no 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 on when to use this tool versus show_overlay, set_scene, or other visual-control siblings. No context about prerequisites (e.g., whether OBS must be connected/running, whether effects require a specific mode), nor 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says it switches the scene but doesn't state what happens to current content, whether it requires a live connection (get_obs_health, reconnect_obs siblings suggest dependency), or whether the switch is immediate or queued. This is a state-changing tool with no behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is concise and has zero waste, but it's under-specification rather than genuine conciseness. One short declarative sentence is appropriate in length but doesn't earn its place by adding meaningful guidance beyond restating the tool's obvious function.
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-changing tool with no annotations, no output schema, and a single undocumented parameter, the description should provide substantially more context. It doesn't explain what 'program' scene means, how it relates to the OBS ecosystem (get_obs_health, reconnect_obs), or what happens on failure. The tool is incomplete for an agent to use safely and correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for documenting the sceneName parameter. It does not. It doesn't specify the format of sceneName (exact name string?), whether it needs to match an existing scene from get_scene_list, or any case-sensitivity or naming conventions. The description adds nothing beyond what the bare schema property name implies.
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 a clear verb+resource ('Switch the current program scene'), but it's thin and doesn't distinguish from siblings like switch_segment or start_show/show_overlay. 'Scene' is somewhat clear given the get_scene_list sibling, but the description alone gives minimal 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 when-to-use or when-not-to-use guidance is provided. There's no direction about when set_scene should be preferred over switch_segment or trigger_effect, nor any exclusions or prerequisites. The context is entirely 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?
No annotations are provided, so the description carries the full burden. It doesn't disclose whether showing an overlay is reversible, whether it affects current scene state, whether it requires an active show, or what side effects occur. The word 'show' implies a visual state change but gives no behavioral details.
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 (three words), which is concise but crosses the line into under-specification. It's not verbose, but the brevity fails to convey meaningful information beyond the title.
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 2 parameters (one requiring a nested free-form 'params' object), no annotations, and no output schema, this description is inadequate. The nested params object needs explanation, and the relationship to other overlay/show tools should be clarified for the agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it doesn't. The overlayId parameter is self-explanatory from its name, but the 'params' object parameter (a nested free-form object) is entirely undocumented—no indication of what keys or values it accepts, which is a significant gap given it's a nested object.
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 'Show an overlay' states the verb ('show') and resource ('overlay') clearly, and it is distinct from the sibling 'hide_overlay'. However, it doesn't clarify what showing an overlay entails (e.g., making it visible in a scene, toggling its display state) or how it differs from triggering an effect or marking highlights.
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. With siblings like start_show, end_show, trigger_effect, and set_scene, there's no explanation of when showing an overlay is the right action versus other scene/effect manipulation tools. The description offers no context about prerequisites like whether a show must be running first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It doesn't state what side effects a snapshot produces, whether it's read-only or mutating, where the snapshot data goes, or what the response format looks like. The name suggests an innocuous operation but nothing is confirmed.
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 excess words. However, it is under-specified rather than appropriately abridged, so the conciseness reflects brevity more than effective compression of necessary information.
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 an optional undocumented parameter, no annotations, no output schema, and no behavioral context, the description is inadequate. The agent lacks information about what the snapshot returns, whether sourceName is needed, and what distinguishes this from sibling tools. More detail is required for a tool of even modest 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 single parameter sourceName is undocumented in the description, and schema description coverage is 0%. The description gives no hint whether sourceName refers to OBS source, a camera input, or the stream itself. With no schema-level documentation either, the agent must guess at the parameter's meaning and whether it's optional.
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 a clear verb+resource ('Take a snapshot of the current stream'), which establishes the basic purpose. However, it doesn't clarify what a 'stream snapshot' entails (is it a video frame, a thumbnail, recording state?) or how it differs from related sibling tools like get_current_show_state or get_obs_health, leaving ambiguity about what the snapshot captures.
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. With 17 sibling tools covering state, health, and show management, the agent has no help distinguishing when a snapshot is appropriate. No exclusions, prerequisites, 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?
No annotations are provided (neither readOnlyHint nor destructiveHint), so the description carries the full burden of behavioral disclosure. It doesn't state whether this is a lightweight metadata operation, whether it affects the broadcast output, whether it persists, or what side effects occur. For a tool with zero annotation coverage, this is a notable gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, zero waste. It's appropriately brief, though it could add useful information without becoming bloated. The structure is clean and front-loaded with the core purpose.
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?
This tool sits in a complex stream-management ecosystem with 16 siblings. Given zero annotations, zero output schema, and an undocumented parameter, the description is insufficient. An agent would not know what a 'highlight point' is, what the description parameter does, what the return value is, or how this interacts with the show lifecycle 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 tool has a single optional 'description' parameter at 0% schema coverage. The description doesn't explain what the description parameter is for - whether it labels the highlight, is stored, or is sent somewhere. With only one parameter, the description could easily explain its purpose, but it doesn't.
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 'Mark a highlight point in the stream' has a clear verb ('mark') and resource ('highlight point in the stream'), explaining what it does at a basic level. However, it doesn't distinguish itself from siblings like take_stream_snapshot or trigger_effect, which could overlap in purpose for an 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?
No guidance is provided on when to use this tool versus alternatives like take_stream_snapshot or trigger_effect. The description gives no context about what a 'highlight point' means in the stream workflow or when marking one is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Set the audio mood profile' reveals that this is a mutation (it sets something), but there's no information about persistence, reversibility, side effects on the mix/route, whether mute_all is destructive to restore, or whether this interacts with start_show/end_show sequencing. The behavioral impact of changing audio mood is entirely undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise single sentence with zero waste. The description is appropriately short for a relatively simple one-parameter tool. Front-loaded with the verb+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?
For a tool that mutates audio state with no output schema and no annotations, there is significant missing context. It doesn't explain what happens when mutes/effects are applied, whether they persist across shows or segments, how it fits into the broadcast workflow, or what observable state change an agent/user should expect. The tool is functionally opaque despite its 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?
Schema description coverage is 100% and the single 'mood' parameter has a full enum with descriptive values. The schema fully documents the accepted values, though the description doesn't explain what each mood does to the actual audio (e.g., does 'hype' boost certain frequencies? does 'mute_all' silence everything?). Since the schema carries the load, 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 says 'Set the audio mood profile.' which identifies a specific verb+resource (set + audio mood). However, it doesn't distinguish what an 'audio mood profile' means or how it differs from sibling tools like trigger_effect or update_source_content which could also affect audio in a show context. There is no explanation of the effect this has on the user's actual audio 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 on when to use this tool versus alternatives. With 17 sibling tools in a broadcast/show context, it's unclear whether this should be called during a live show, before a show starts, or in any context. The enum options (talk, game_focus, hype, cinema, celebration, mute_all) suggest scenarios, but the description provides no contextual guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The tool performs a show-starting mutation, but the description doesn't disclose whether this affects existing state destructively, whether it requires OBS to be connected, what happens to the previous show state if one is active, whether it can fail mid-opening, or what triggers are involved. 'Initializes state' is vague about what state gets reset or overwritten. Given zero annotation coverage for what appears to be a significant state-mutating operation, this is a notable gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief—two sentences, zero wasted words. It front-loads the key verb and purpose. However, it's arguably under-specified rather than efficiently concise; the brevity comes at the cost of missing behavioral and usage context. Still, as written, it's structurally clean and scannable.
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?
This is a show-lifecycle mutation tool with no output schema, no annotations, and moderately documented parameters. An AI agent needs to know what 'initializes state' entails, whether re-invoking start_show mid-show resets everything, how it interacts with the many siblings (get_current_show_state, set_safety_mode, reconnect_obs), and what success/failure looks like. The description is too thin to support confident, correct invocation in a complex show-control 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 50%, with show_template_id and start_segment_id documented in the schema. The description mentions 'loads show template' which maps to show_template_id, adding some context about its role. However, it does not explain the behavior of the 'options' object (skip_opening vs. start_segment_id interaction—are they mutually exclusive? what takes precedence?), nor the default template behavior. The description adds marginal value over the schema for half the parameters but leaves the options sub-object semantics under-explained.
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 'Start a show and execute opening sequence. Loads show template and initializes state.' This uses a clear verb (start) and resource (show), and hints at what happens (loads template, initializes state). However, it doesn't explicitly distinguish from the sibling 'end_show' which is the obvious counterpart, nor does it clarify how it relates to 'switch_segment' or 'extend_segment' which are all show-lifecycle tools. The purpose is clear but sibling differentiation is weak.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance is given. There is no mention of when start_show is appropriate vs. alternative tools like switch_segment or when it's not appropriate. The description doesn't state prerequisites (e.g., does the show need to be fully configured first? must OBS be connected via the reconnect_obs sibling? should safety_mode be set?). Usage context is essentially 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?
No annotations are provided, so the description carries full behavioral disclosure burden. It doesn't disclose whether this is destructive, whether it requires OBS to be running/connected, whether partial updates are supported, or what happens with the sourceType parameter mismatch (e.g., updating an image source with text content). For a mutation tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One concise sentence with no wasted words. It's front-loaded and efficient. Could add a bit more detail without becoming verbose, but structurally it's clean.
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?
This is a mutation tool with no annotations, no output schema, 0% schema description coverage, and a sourceType enum that implies type-specific content semantics. The description is far too thin for the complexity involved. It should at minimum explain how content differs per sourceType and whether OBS connectivity is required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no parameter-level meaning. The schema shows content (string), sourceName (string), and sourceType (enum: text/browser/image), but the description doesn't explain how content maps across source types (e.g., HTML for browser, URL/file path for image). The description fails to compensate for the 0% 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 states a clear verb+resource: 'Update the content of an OBS source.' It's specific about the action (update content) and resource (OBS source). However, it doesn't differentiate among the source types (text, browser, image), and siblings like show_overlay/hide_overlay also interact with OBS sources, so some differentiation would help.
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, what content formats are expected per sourceType, or prerequisites (e.g., does the source need to already exist? Is OBS connected?). No exclusions or alternatives are mentioned, leaving the agent to infer usage context from the schema alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure, but it only states the action without revealing consequences. It doesn't disclose whether extending the timer affects OBS, whether it requires the show to be running, what the maximum total segment length is, or how the change impacts downstream segments. For a mutation-like timer operation with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with zero wasted words. Perfectly sized for a simple tool with one parameter. No redundancy, no padding.
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 simple 1-parameter tool, the description covers the basic action, but with no annotations, no output schema, and no behavioral guidance, the overall picture is incomplete. The agent lacks information about prerequisites (is a show active?), side effects, and what success looks like. Given the surrounding show-management siblings, more context would meaningfully improve the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the single 'minutes' parameter fully documented ('Minutes to extend (1-120)'). The description adds no additional parameter meaning beyond what the schema provides, so the baseline 3 applies. The boundary (1-120) is useful but comes from the schema, not the description.
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 'Extend the current segment's timer' uses a specific verb ('extend') and resource ('current segment's timer'), making the core purpose clear. However, it doesn't distinguish itself from the sibling 'switch_segment' tool, and could be more explicit about what 'extending a timer' means operationally. It's adequate but minimal.
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 (extending the current segment's timer), but provides no explicit when-to-use guidance or exclusions. Among siblings, it's reasonably distinguishable from switch_segment (switching vs. extending), but no guidance is given about when one should be preferred over the other. The context of show timing is implicitly clear from siblings like start_show/end_show.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not state whether this is a write/mutation operation, whether it requires specific permissions, whether changes take effect immediately, or whether there's any side effect on connected services (e.g., OBS). 'Set' implies mutation but the consequences are undisclosed.
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 efficient sentence with zero waste. It's front-loaded with the verb and resource, and the enum values provide immediate clarity. Could arguably be too terse, but there's no redundancy or 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?
For a mutation tool with no annotations and no output schema, this description is underspecified. It doesn't explain what each safety mode does, what return value or confirmation is produced, whether it affects OBS state, or how it interacts with debug/get_debug_config siblings. Given zero annotation coverage, the description should carry more behavioral 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 the enum values are documented. The description restates the enum options (strict, normal, debug) which adds marginal value, but it doesn't clarify what each mode means behaviorally or what effect each has. 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'set' and the resource 'safety mode' clearly. It enumerates the valid mode values (strict, normal, debug), which helps an agent understand the operation. However, it doesn't differentiate from siblings well — though none of the sibling names are obviously related to safety mode, so the purpose is adequately 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?
The description gives no guidance on when to use this tool versus alternatives, when to adjust safety mode, or what scenarios warrant changing it. No when-not-to-use instructions or prerequisites are provided. For a configuration tool, context on why/when to change safety mode would be valuable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. The description only states what the tool does but not what happens during the transition (whether the current segment stops, what state changes occur, whether it requires the show to be live). Not a destructive/read operation context is conveyed. Transition effects are mentioned only in params, not behavior.
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, efficient sentence with no wasted words or filler. It's appropriately minimal for its purpose, though very brief. No redundancy or fluff.
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 annotations, no output schema, and nested parameters, the description is too sparse. It doesn't explain return behavior, error conditions (e.g., invalid segment_id), or whether a show must be active. Given the complexity (nested options, show state implications), the description should provide more 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?
Schema coverage is 50% — the segment_id parameter is described ('ID of the segment to switch to') but the options object is in a nested structure. The description tells us nothing about the 'options' object or its sub-parameters beyond what the schema provides. Baseline 3 applies since half the parameters are documented in schema; description adds no extra semantic 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 uses a specific verb+resource ('Switch to a different segment of the show'), which clearly states the action and target. It distinguishes from siblings like start_show/end_show since it targets a specific segment rather than show lifecycle, though it doesn't explicitly contrast with sibling extend_segment. Clear enough for basic understanding.
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 like extend_segment or set_scene. There's no mention of when segment switching is appropriate, prerequisites (e.g., show must be running), or exclusions. The description provides no decision guidance for the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It reveals this is a read-only operation ('Get masked configuration') that returns masked data, which is useful behavioral context (noting masking). However, it doesn't disclose what 'masked' means precisely, what the response shape is, whether it has side effects, or what 'connection issues' context implies. Some value added but gaps remain.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single concise sentence that front-loads the key action (Get) and purpose (masked configuration for debugging). No wasted words. It is efficient, though with no parameters or usage guidance it might benefit from slightly more 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 tool has no parameters, no output schema, and no annotations, the description carries the full explanatory burden. It communicates the core read-only diagnostic intent, and the masking detail adds context. However, it doesn't describe the return structure or relationship to get_obs_health and reconnect_obs, which are likely related diagnostic tools, so completeness is moderate.
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 0 parameters, and schema description coverage is 100%. With no parameters to document, the description needs no parameter explanation. The baseline of 4 for 0-parameter tools applies—the description correctly avoids fabricating parameter detail where none exists.
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 'Get masked configuration for debugging connection issues' identifies a specific verb (get) and resource (configuration), and the purpose of debugging connection issues. It's reasonably clear, though it doesn't specify what the configuration contains or what kind of debugging it supports. It does distinguish from siblings like get_obs_health and get_scene_list, though implicitly rather than explicitly.
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 vs alternatives. Siblings like get_obs_health, reconnect_obs, and get_current_show_state suggest overlapping diagnostics functions, but the description doesn't say when to choose this tool over them. There's no when/when-not guidance at all.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full transparency burden. It doesn't disclose whether this is a read-only probe, whether it might have side effects, how the returned state is structured, or whether polling is costly/frequent. For a status tool the read-only nature is implied but not 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?
One efficient sentence that states the action and its scope. Zero waste, front-loaded with the verb. Appropriate for a simple zero-parameter status 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 zero-parameter, no-output-schema tool, the description is reasonably complete on purpose. However, it does not describe the return format, frequency expectations for polling, or whether this is safe to call repeatedly. Sibling tools (get_obs_health, get_debug_config) offer overlapping 'get state' functions, and the description alone doesn't clarify where the boundaries are.
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 0 parameters with 100% schema coverage, so the baseline is 4. The description doesn't need to explain parameters. The description briefly indicates what the returned state covers (segments, overlays, timers), which is essentially all the semantic value 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?
Clear verb+resource: 'get current show state.' The description names the areas covered (segments, overlays, timers), which is specific enough to distinguish purpose. It doesn't explicitly differentiate from siblings like get_debug_config or get_obs_health, but the subject matter is distinct.
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 vs alternatives like get_obs_health or get_scene_list. There's no mention of when calling is appropriate, whether it should precede actions, or how often to poll. The 'current show state' context is implied but no exclusions or alternatives 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?
No annotations provided, so the description carries the full behavioral burden. It's a read/query operation by nature ('Get list'), but nothing is disclosed about whether it requires a live OBS connection, whether it can fail when OBS is offline, what happens if no scenes exist, or whether the list is cached or real-time. For a state-querying tool with zero annotation coverage, more disclosure is warranted.
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, zero waste. It communicates the core function in minimal words, which is entirely appropriate for a zero-parameter list 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 list-returning tool with no parameters and no output schema, the description is mostly adequate. However, there's no output schema, so the tool doesn't explain what the returned list contains (scene names? objects with properties? ordering?). Without an output schema and with siblings like get_obs_health and get_current_show_state, some detail about what fields/format the scene list returns 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?
There are zero parameters, so the description carries no parameter burden. Baseline of 4 applies for a 0-parameter tool. Nothing to add beyond what the schema already conveys.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb+resource ('Get ... list ... scenes') and states it lists available scenes. It distinguishes from siblings like get_current_show_state, which returns show state rather than scene availability. Purpose is clear but doesn't elaborate on what 'available' means or what the returned scene details contain.
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 like set_scene or get_current_show_state. The description doesn't clarify whether this is a pre-broadcast discovery step, whether it pairs with set_scene for selection, or how it differs from getting the current scene. No when/when-not guidance provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that ending can optionally play an ending sequence and stop streaming/recording, and the schema adds safety permission requirements. However, it doesn't disclose whether ending is reversible, whether it affects the current show state irreversibly, or any behavioral side effects beyond what's named.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One clear sentence stating the primary action plus optional behaviors. Zero wasted words, front-loaded with the core purpose. Very efficient for the information conveyed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional nested options object and no output schema, the description covers the main action and optional variants. However, with no annotations and zero schema coverage in the description, it could benefit from noting what happens to the show state after ending (is it resumable? completely terminated?) and whether any prerequisite state is required (must a show be active?).
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 0%, so the description must compensate. However, the description itself names the optional behaviors (play ending, stop streaming/recording) which maps to the options object. The description doesn't explain the options structure nesting, but the schema does document the three boolean fields well. The description adds marginal value beyond the schema here, so baseline 3 is fair.
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 'End the current show' with a specific verb (end) and resource (show), and adds the optional behaviors of playing an ending sequence and stopping streaming/recording. It distinguishes from siblings like start_show and switch_segment clearly. Slightly lacking in that it doesn't explicitly contrast with any sibling.
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 doesn't mention that stopping streaming/recording requires safety permission (though the schema does note this for those options) or when one might want to end without playing the ending sequence. No alternative tool references provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'Try to reconnect' suggests a potentially mutating/connection-changing operation but doesn't disclose what happens on success/failure, whether it interrupts ongoing operations, whether it's idempotent, or if it requires any special state. The description adds minimal behavioral context beyond what the name alone implies. It also doesn't clarify if reconnection could disrupt active sessions or lose data.
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 with no filler. The phrase 'using current configuration' earns its place by explaining why no parameters are needed. Could arguably benefit from a brief note on when to invoke, but for its length it's efficient 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 zero-parameter, no-output-schema tool, the description is minimally adequate but lacks depth. It doesn't explain what the reconnect attempt does in practical terms (e.g., does it block until success/failure?), what the return value indicates, or how an agent should respond to success vs. failure. Given the sibling get_obs_health exists, it would be valuable to note the relationship (e.g., check health before/after reconnect).
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 with 100% schema coverage (an empty object schema), so there's nothing for the description to compensate for. The phrase 'using current configuration' clarifies that no parameters are needed because the tool relies on stored/persisted configuration, which adds meaning beyond the empty schema. Baseline 4 for a zero-parameter tool 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 states a specific verb+resource ('Try to reconnect to OBS WebSocket') with a clear qualifier ('using current configuration'). It clearly distinguishes from siblings like get_obs_health (which checks status) versus this which actively reconnects. Slightly ambiguous whether this establishes a new connection or re-establishes a dropped one, but the purpose is 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 context (when connection is down, attempt to reconnect), but provides no explicit guidance on when NOT to use it or alternatives. It doesn't state whether this is a recovery action after failures, a startup action, or how it relates to get_obs_health as a diagnostic precursor. There's no explicit event-when-to-use guidance beyond the implied 'try to reconnect' context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does indicate this is a read-only status tool ('Get...status and health metrics'), which implies safety. But it doesn't disclose what specific health metrics are returned, whether it attempts a connection refresh, or whether it has side effects like pinging OBS.
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 waste. It names the tool behavior and the resource it covers. Efficiently front-loaded and appropriately sized for a zero-parameter health-check 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 zero-parameter, no-output-schema tool, the description is largely adequate. However, given the sibling set includes reconnect_obs, it would be valuable to clarify whether this tool performs active probing or only reports cached/passive status, and whether any connection state implications follow from calling it. No output schema means the description should hint at what health metrics look like, which it does only superficially.
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 (trivially satisfied since there's nothing to document), the description faces no parameter burden. The baseline of 4 for no-parameter tools is appropriate—there are no parameters requiring additional meaning.
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: retrieving OBS connection status and health metrics. The verb 'get' plus the specific resource ('OBS connection status and health metrics') makes the purpose clear. However, it doesn't explicitly differentiate from sibling tools like reconnect_obs or get_debug_config, though 'health metrics' adds distinguishing context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is a read/health-check tool that should be used when an agent needs OBS connection state. However, it doesn't explicitly state when NOT to use it or reference alternatives—e.g., it doesn't say to use reconnect_obs when trying to fix a connection, or get_scene_list for scene info. The context is clear but lacks exclusions.
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-showrunner-mcp MCP server](https://glama.ai/mcp/servers/takurot/obs-showrunner-mcp/badges/card.svg)](https://glama.ai/mcp/servers/takurot/obs-showrunner-mcp)

Score Badge

Copy to your README.md:

[![obs-showrunner-mcp MCP server](https://glama.ai/mcp/servers/takurot/obs-showrunner-mcp/badges/score.svg)](https://glama.ai/mcp/servers/takurot/obs-showrunner-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/takurot/obs-showrunner-mcp'

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