Skip to main content
Glama
Giancarlo26

obs-action-history

by Giancarlo26

obs_output_control

Start, stop, or toggle any OBS output by name, including replay buffer and virtual camera. Requires confirmation to stop service outputs like live streams.

Instructions

Start, stop or toggle any output by name - covers StartOutput, StopOutput and ToggleOutput. This is the general lever for outputs that have no dedicated tool: the replay buffer, the virtual camera, and above all the outputs a plugin brought with it, such as the vertical canvas's own recording on the reference machine. Without it, a whole second canvas is unreachable.

Know which output you are aiming at before you fire. Stopping the SERVICE output ends the broadcast for every viewer on every platform simultaneously - here that is adv_stream, the one RTMP connection into the local relay that feeds Twitch, YouTube and Kick, so there is no such thing as stopping just one platform from OBS. Stopping the local recording (adv_file_output) is merely annoying by comparison. Stopping a replay buffer discards what is in memory. Because these are so far apart in consequence and the names give no hint, this tool refuses to stop a service output unless you pass confirm:true, and names the output in the refusal.

For the main stream and the main recording, prefer obs_stream_control and obs_record_control. Those are the paths the rest of the reference machine's tooling and OBS's own state follow; this tool operates on the raw output and is the right choice only for what they do not cover.

'toggle' is convenient and dangerous in the same way: it decides based on state you have not looked at, so a toggle aimed at something you believed was stopped will stop it instead. Check obs_output_status first, or use explicit start/stop. Starting an already-running output, or stopping an already-stopped one, is an error rather than a no-op - this tool reports the state it found instead of failing obscurely.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
actionYes'toggle' flips whatever the current state is - prefer explicit start/stop.
confirmNoRequired (true) only to stop or toggle-off an output that feeds a streaming service, i.e. to end the live broadcast on every platform at once.
outputNameYesExact output name from obs_list_outputs.
Behavior5/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 extensively discloses high-stakes behaviors: stopping the service output ends the broadcast everywhere, stopping a replay buffer discards memory, the tool refuses to stop a service output without confirm:true, and starting/stopping an already-running/stopped output is an error.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but every section earns its place: scope in the first paragraph, severe consequences in the second, alternatives in the third, and toggle/error behavior in the fourth. Front-loads the core purpose then layers risks logically.

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 three parameters and no output schema, the description covers intended use, exclusions, safety conditions, error behavior, and tool relationships. It even hints at the return behavior ('reports the state it found instead of failing obscurely'), making the tool predictable to an agent.

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?

Although schema coverage is 100%, the description adds vital examples and scenario context: concrete output names like adv_stream and adv_file_output, what confirm:true is for, and why toggle is risky. This significantly enriches the parameter meaning beyond the schema's field descriptions.

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 starts with a specific verb+resource: 'Start, stop or toggle any output by name' and covers StartOutput, StopOutput, ToggleOutput. It clearly distinguishes itself from sibling tools like obs_stream_control and obs_record_control by labeling itself as the general lever for outputs without dedicated tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit guidance is provided on when to use this tool vs. alternatives: 'For the main stream and the main recording, prefer obs_stream_control and obs_record_control.' It also advises checking obs_output_status before toggling and using explicit start/stop over toggle.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

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/Giancarlo26/obs-action-history'

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