cmw_rf_route_set

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

With no annotations, the description carries the full burden of behavioral disclosure. It does reveal a key behavioral trait: routing is per-application and converters serve one application at a time, leading to conflicts. However, it omits other important behaviors such as side effects on previously set routes, error behavior in conflict situations, and any prerequisites or reversibility concerns.

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 two sentences, front-loaded with the action and example, followed by two essential caveats about per-application isolation and converter conflicts. Every phrase contributes meaning with no redundancy or filler.

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 purpose and the key conflict behavior but leaves gaps: it does not mention the corresponding getter cmw_rf_route_get, does not explain what happens on a resource conflict (error? override?), and does not clarify the role of parameters like host, port, and meas_instance. Given 5 parameters, no annotations, and no output schema, the description is functional but not comprehensive.

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 'path' and 'application'; the description adds a concrete example and clarifies the per-application semantic. Yet with only 40% schema description coverage, host, port, and meas_instance remain unexplained in both schema and description. The description provides some added meaning but does not fully compensate for the missing parameter 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 clearly states the tool's function: 'Route a measurement or generator application to a front-panel connector and internal converter', with a concrete example ('RF1C,RX1'). It also distinguishes from the sibling getter cmw_rf_route_get by emphasizing the per-application routing behavior, making the purpose 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 provides contextual guidance by explaining that routing is per-application and that converters cause resource conflicts when shared. This implies when to use it and what to watch for. However, it does not explicitly name alternatives like cmw_rf_route_get for reading routing or cmw_set_signal_path for other path settings, so a fully explicit when/when-not comparison is missing.

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