start_output

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

With no annotations provided, the description carries the full burden of disclosure. It only states 'Start a named output,' which reveals no side effects, error conditions, idempotency, or return behavior. An agent has no idea whether starting an already-running output fails, is a no-op, or resets the output. This is almost entirely uninformative.

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

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

The description is extremely short and front-loaded, with no wasted words. However, it is under-specified to the point where it adds little value beyond the tool name itself. It is not bloated, but it also does not effectively use the available space to convey necessary information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with a single parameter and no output schema, the description should at least explain what an 'output' is in this context, whether a named output must be pre-configured, and what happens on success or failure. Given the large set of sibling tools related to outputs (get_output_status, toggle_output, stop_output, etc.), the description is too sparse to allow reliable tool selection and invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has a single required parameter output_name with 0% schema description coverage. The description's phrase 'named output' merely echoes the parameter name and does not add any concrete meaning about what format the name should take, where it comes from, or how it maps to an existing output. The description fails to compensate for the lack of schema documentation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Start a named output' clearly identifies the action (start) and the resource (output), and the qualifier 'named' indicates that a specific output identifier is required. It distinguishes from sibling tools like stop_output and toggle_output through the verb choice. However, it does not explicitly clarify what 'output' refers to in the broader context of stream/record/replay buffer outputs.

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

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

No guidance is given on when to use start_output versus the more specific start_stream, start_record, start_virtual_cam, or start_replay_buffer. There is no mention of prerequisites, such as whether the output must already exist or be configured. The description provides no contextual cues for an agent to decide when this tool is the right choice.

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