Skip to main content
Glama
Giancarlo26

obs-action-history

by Giancarlo26

obs_hotkey_key

Simulate pressing a key combination in OBS to trigger manually bound hotkeys with no named action or request. Be cautious: unused keys may be ignored, or unexpected bindings fire.

Instructions

Press a key combination at OBS, as if typed while OBS had focus. Use this only when an action has no name in obs_hotkey_list and no request - for instance a plugin binding a user configured by hand in Settings > Hotkeys.

It is a blunt instrument and fails silently in both directions. If nothing is bound to the combination, OBS accepts the request and does nothing at all. If something you did not expect is bound to it, that fires instead - and OBS's default bindings include stopping the stream and the recording. There is no request that reports what is bound to what, so you cannot check first.

keyId values are the OBS_KEY_* identifiers from libobs/obs-hotkeys.h - OBS_KEY_F1, OBS_KEY_A, OBS_KEY_SPACE, OBS_KEY_NUM1 and so on - not browser key names and not raw characters. Modifiers go in keyModifiers, not in keyId.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
keyIdNoOBS key identifier, e.g. 'OBS_KEY_F5'. Omitted means no key is pressed, only modifiers.
keyModifiersNoModifier keys held during the press. Omitted entirely means none.
Behavior5/5

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

With no annotations provided, the description fully carries behavioral disclosure. It explicitly calls itself a 'blunt instrument' that fails silently, details what happens when nothing is bound (OBS accepts and does nothing) and when unexpected bindings fire (including stopping stream/recording), and notes the impossibility of verifying bindings beforehand.

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 well-structured in three clear paragraphs: purpose and usage, behavioral warnings, and parameter format. Each sentence adds value without redundancy; the length is justified by the tool's risk profile and the need to emphasize safety precautions.

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 tool with only two parameters and no output schema, the description covers all essential context: when to use, safety risks, parameter constraints, and examples. It addresses the tool's dangerous potential thoroughly, making it complete for safe operation.

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 schema already documents both parameters with descriptions (coverage 100%), but the description adds crucial semantics: keyId must be OBS_KEY_* identifiers from libobs/obs-hotkeys.h with examples, clarifying it's not browser key names or raw characters, and that modifiers belong in keyModifiers. This extends the schema's meaning, though the schema already provided examples.

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 clearly states the tool presses a key combination at OBS, acting as if typed while OBS has focus. It distinguishes this from alternatives by specifying it's only for actions without a name in obs_hotkey_list and no request, differentiating it from sibling tools like obs_hotkey_trigger.

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?

Provides explicit guidance: use only when an action has no name in obs_hotkey_list and no request, with a concrete example (plugin binding configured by hand). It also warns against misuse, explaining the risks of unintended bindings and that no check is possible, giving clear when-not-to-use guidance.

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