fl_transport

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

Goes well beyond the annotations: play always jumps to the start rather than resuming, playback restarts if re-invoked, no file is modified, FL is launched if absent but with nothing open, and the return value is {playing, mode}. It also states the platform constraint (Windows with FL Studio only). This is consistent with destructiveHint=false and idempotentHint=true.

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 core action is front-loaded in the first clause, and no sentence is filler. It is a dense single paragraph with heavy parenthetical nesting, which slightly hurts scanability for an agent extracting the play/stop contract.

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?

There is no output schema, but the description supplies the return shape ({playing, mode}) plus the launch-state caveat and the cross-tool handoffs needed to actually get results. Nothing an agent needs to call this correctly is missing.

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 100%, so the baseline is 3, but the description adds real meaning: 'song' plays the arrangement, 'pattern' loops a single pattern which must be selected first, and omitting mode preserves FL's existing setting. The mode/pattern interaction is documented better here than in the schema alone.

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?

States a specific verb pair (play/stop) over a specific resource (the project open in the running FL) and immediately scopes it: 'it changes nothing in any file.' It also distinguishes itself from siblings by name, pointing to fl_render for audio output and project_write for opening a project.

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?

Explicitly covers when each action applies, what 'play' does when already playing (restarts from start), how mode interacts with pattern, and what happens when FL is not running. It names the alternatives and the exact conditions that select them (project_write(open=true), play='song'; fl_render to save and close).

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