osc_set

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

With no annotations, the description takes on the burden and does well: it reveals value type coercion (float/int/string based on form), the force_type override mechanism, and the dangerous 'can change anything on a live console' side effect. It does not cover response behavior or error cases, but the core risk is clearly disclosed.

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 with no filler. The core action is front-loaded, the type behavior is stated in one clause, and the caution is compact yet impactful. Every sentence earns its place.

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 destructive raw-write tool, the description conveys what it does, how values are typed, how to override typing, and the risk. It lacks explicit return/output information, but this is acceptable given no output schema and the nature of a raw OSC write command. Sibling context further reinforces its purpose.

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?

Schema coverage is 0%, but the description meaningfully explains value ('sent as float/int/string based on its form'), force_type (override), and the nature of address ('raw OSC address'). The address pattern and required-ness remain only in the schema, so this isn't a perfect five, but it is far above baseline.

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?

Description states a specific verb ('Write'), resource ('raw OSC address on the WING'), and scope ('any'), clearly distinguishing it from sibling tools like set_fader or set_mute that target specific parameters. The word 'raw' signals this is a low-level universal tool.

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 implies this is for arbitrary addresses that specific sibling tools don't cover, but never explicitly says 'use this when no dedicated tool exists' or mentions alternatives. The CAUTION warning gives context about appropriate care but not about selection criteria.

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