set_trigger

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

With no annotations, the description carries the behavioral burden and does so well. It reveals a surprising default behavior (always selects EDGE even with no arguments), promises a readback return, and flags model-specific EXT availability. It does not cover validation or failure behavior, but there is no contradiction with any structured metadata.

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?

Two sentences, front-loaded with the most important default behavior, followed by compact parameter and compatibility notes. Every sentence earns its place with no filler or repetition.

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?

The description covers the core behavior, no-argument default, return type, slope semantics, and model-specific source limitations, while the schema handles level and source. It lacks only an explicit readback format and a usage-vs-alternatives note, neither of which is critical for this simple setter.

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 schema already documents level and source, so the description adds value by explaining the slope enum meanings (POS rises, NEG falls, RFAL accepts either edge) and the EXT source model limitations. With schema description coverage at 67%, this is a solid supplement rather than redundant.

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 leads with 'Always selects EDGE, even with no arguments', making the operation and default behavior explicit. It clearly identifies the trigger domain and explains slope options, so an agent can distinguish it from channel or timebase setters. It stops short of an explicit 'Sets the trigger' framing, but the intended action is unambiguous.

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?

The description gives concrete selection guidance: POS means rising edge, NEG means falling edge, RFAL accepts either edge, and EXT is only available on specific models. It does not name sibling tools or state when to prefer this over scpi_execute, but for a dedicated setter the context is sufficient.

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