Skip to main content
Glama
Giancarlo26

obs-action-history

by Giancarlo26

obs_rename_input

Rename an OBS source to a new name not already in use. Scene references follow automatically, but external automations using the old name will not.

Instructions

Rename a source. Inside OBS this is safe and complete: scene items reference the source itself, not its name, so every scene follows the rename and nothing breaks visually.

Outside OBS it is the opposite, and that is the real risk. Everything that automates OBS addresses sources BY NAME over the websocket - health checks asking whether a mic is producing sound, audio tooling, scene builders, and every tool call in this server. None of them are updated by a rename, none of them fail loudly, and the symptom arrives later as 'that check stopped reporting' rather than as an error. A source name that has drifted from what it now shows is often still worth keeping for exactly this reason. Prefer renaming the SCENE, which nothing addresses by name, or leaving it alone.

Names are unique across the whole collection, so a rename onto a name already in use fails.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
inputNameYesCurrent exact input name.
newInputNameYesNew name. Must not already be in use by another input.
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full behavioral disclosure burden. It explains internal safety, external silent breakage, delayed symptoms, uniqueness constraints, and failure behavior when the new name is already in use. This is exceptionally transparent.

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

Conciseness5/5

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

The description is front-loaded with the core purpose, then organized into internal safety, external risk, and uniqueness. Though longer than average, every sentence contributes necessary guidance for a deceptively risky operation.

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 2-parameter tool with no annotations and no output schema, the description fully covers purpose, effect, risk, failure modes, alternatives, and naming constraints. No critical context is missing.

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 baseline is 3. The description adds meaningful context beyond the schema by explaining why the new name matters for external automation and reinforcing that duplicate names fail. This elevates the score above 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 opens with a clear, specific verb+object statement: 'Rename a source.' It also distinguishes this tool from the broader OBS tool family by clarifying exactly what is renamed and why the rename behaves differently internally vs externally.

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?

The description provides explicit when-not-to-use guidance: renaming a source breaks external automation that references sources by name. It recommends renaming the scene or leaving the source name alone, giving clear alternatives and a strong risk assessment.

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