Skip to main content
Glama
Giancarlo26

obs-action-history

by Giancarlo26

obs_scene_item_transform

Read or modify the full transform of an OBS scene item—position, scale, rotation, alignment, crop, and bounds—by specifying scene and item IDs. Only provided fields change, enabling targeted adjustments.

Instructions

The complete transform: position, scale, rotation, alignment, crop and bounds. obs_set_source_transform covers position, scale and crop only; this one reaches the rest. Call with just sceneName and sceneItemId to READ the current transform, including the read-only width/height/sourceWidth/sourceHeight that tell you how big the thing actually is on canvas right now.

Only the fields you pass change; everything else keeps its current value.

BOUNDS ARE INERT WITHOUT boundsType. boundsWidth, boundsHeight and boundsAlignment are ignored while boundsType is OBS_BOUNDS_NONE, which is the default, so setting a bounding box and nothing else accomplishes nothing at all and reports success. Set boundsType in the same call. Bounds are the right tool for a slot of fixed size - OBS_BOUNDS_SCALE_INNER fits the source inside the box keeping its aspect ratio, which is how you drop a camera of unknown resolution into a layout without doing the arithmetic. Once bounds are active they drive the size and scaleX/scaleY stop being the thing to adjust.

ALIGNMENT IS A BITMASK, NOT AN ENUM: 0 centre, 1 left, 2 right, 4 top, 8 bottom, added together. 5 is top-left and is what every item on the reference machine uses. It sets which point of the source positionX/positionY actually refers to, so changing alignment alone appears to teleport the source even though position never changed.

Crop is measured in SOURCE pixels, before scaling, and cuts in from each edge. width/height/sourceWidth/sourceHeight cannot be written - to resize, set scale, or use bounds.

A source moved off the canvas is still ENABLED and still renders and, more to the point, its audio still plays. Parking something at x=2600 on a 1920 canvas does not silence it. That is what doubled both voices on day one, from a phone parked out of frame but unmuted; it is also used deliberately here, because the mic and music sources are off-canvas precisely so they stay audible without taking up pixels. Hiding a source with obs_set_source_visible DOES cut its audio, which is why those are parked rather than hidden. Choose the one you mean.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
scaleXNoHorizontal scale. 1 = native size. Negative flips.
scaleYNoVertical scale. 1 = native size. Negative flips.
cropTopNoSource pixels cut from the top.
cropLeftNoSource pixels cut from the left, 0 to 100000.
rotationNoDegrees clockwise, -360 to 360.
alignmentNoBitmask: 0 centre, 1 left, 2 right, 4 top, 8 bottom. 5 = top-left.
cropRightNoSource pixels cut from the right.
positionXNoCanvas x of the alignment point.
positionYNoCanvas y of the alignment point.
sceneNameYesScene holding the item.
boundsTypeNoRequired for any bounds field to take effect.
cropBottomNoSource pixels cut from the bottom.
boundsWidthNoBounding box width, 1 to 90001. Needs boundsType.
sceneItemIdYesItem id from obs_list_sources_in_scene. Unique within this scene only.
boundsHeightNoBounding box height, 1 to 90001. Needs boundsType.
cropToBoundsNoClip anything overflowing the bounding box. Needs boundsType.
boundsAlignmentNoSame bitmask as alignment; where the source sits inside the box. 0 = centred.
Behavior5/5

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

With no annotations, the description carries the full load and does so exceptionally. It reveals that calling with only sceneName and sceneItemId reads the current transform, that only passed fields change, that bounds are ignored without boundsType, that alignment is a bitmask causing teleport-like behavior, that crop is in source pixels, and that read-only fields cannot be written. The off-canvas audio gotcha is an invaluable behavioral disclosure not derivable from any schema.

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 sentence earns its place, covering complex interactions and critical warnings without repetition. Clear section breaks (BOUNDS, ALIGNMENT, Crop, off-canvas) front-load the most important constraints. The summary sentence, read/write usage note, and warnings are each purposeful and non-redundant.

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 17-parameter tool with no annotations and no output schema, this description is exceptionally complete. It covers parameter interactions, read vs. write behavior, units, edge cases (e.g., off-canvas audio), and provides real-world examples. Nothing important is left unexplained for an agent to safely invoke this tool.

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 substantial meaning beyond the schema. It explains the alignment bitmask's teleport effect, the dependency of boundsWidth/boundsHeight/boundsAlignment on boundsType, why scaleX/scaleY become irrelevant after bounds activation, and the precise meaning of crop units. It also introduces read-only derived fields (width/height/sourceWidth/sourceHeight) not present in 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 opens with 'The complete transform: position, scale, rotation, alignment, crop and bounds,' naming the exact verb and resource scope. It also clearly distinguishes itself from the sibling obs_set_source_transform, which 'covers position, scale and crop only; this one reaches the rest.' This is a specific, differentiating purpose statement.

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?

Usage guidance is explicit and practical. It tells the agent when to use this tool instead of obs_set_source_transform (when rotation, alignment, or bounds are needed) and when to use obs_set_source_visible instead of off-canvas positioning (hiding cuts audio, parking does not). It also advises that bounds are appropriate for a fixed-size slot and that scaleX/scaleY stop being the thing to adjust once bounds are active.

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