Skip to main content
Glama

get_effective_output_bus

Read-onlyIdempotent

Resolves the inherited output bus for an Actor-Mixer object by tracing ancestor overrides, returning the effective bus path and HDR window status.

Instructions

Resolve the effective (inherited) output bus for an Actor-Mixer hierarchy object.

WAAPI's @OutputBus returns the LOCAL value, which defaults to "Master Audio Bus" when an object has not set Override Output. This tool walks the ancestor chain to find the first non-default @OutputBus assignment and returns its full bus path.

Args: object_path: Project path. e.g. "\Actor-Mixer Hierarchy\Default Work Unit\SFX\Barrage" object_guid: GUID. e.g. "{aabbcc00-1122-3344-5566-77889900aabb}" object_name_with_type: type:name. e.g. "Sound:Barrage"

Provide exactly one of object_path, object_guid, or object_name_with_type.

Returns: object: {name, path, type} of the queried object effective_bus: {id, name} of the resolved output bus bus_path: full project path of the bus (e.g. "\Master-Mixer Hierarchy\Default Work Unit\Master Audio Bus\SFX") is_hdr: whether the object is inside an HDR window (true if the resolved bus or any of its bus ancestors has HdrEnable=true) hdr_bus: {id, name, path} of the bus that establishes the HDR window, or null if not in one set_by: "self", the ancestor path that sets the override, or "default (no ancestor overrides)"

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
object_pathNo
object_guidNo
object_name_with_typeNo
Behavior4/5

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

Annotations already declare readOnly and idempotent, but the description adds behavioral details: walking ancestor chain, returning effective bus, HDR detection, and explaining the difference from local @OutputBus. This adds significant context beyond annotations.

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 well-structured with a clear opening, parameter list, and return explanation. It is slightly verbose but each section earns its place. No wasted sentences.

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?

The tool has moderate complexity with inheritance and multiple return fields. The description covers inputs, behavior, and all return fields comprehensively. Despite no output schema, the return structure is fully documented.

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?

With 0% schema description coverage, the description fully compensates by explaining each parameter with format examples (project path, GUID, type:name) and the constraint to provide exactly one. This is essential for correct invocation.

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 it resolves the effective inherited output bus for an Actor-Mixer hierarchy object, distinguishing itself from WAAPI's local @OutputBus. The verb 'Resolve' and resource 'output bus' are specific, and sibling tools do not overlap.

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 provides parameter usage guidance (provide exactly one of three identifiers) but does not explicitly state when to use this tool over siblings or context. It implies its purpose but lacks situational guidelines.

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/silver-rain-dev/sk-wwise-mcp'

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