get_sequence_tracks

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

Annotations already establish readOnly/idempotent/no-destroy semantics, and the description reinforces with 'Read-only' while adding genuinely useful context: no open Sequencer is required. It also details the output shape (display name, track name, class, section count, nested bindings), though it does not mention any pagination or size limits on large sequences.

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?

Purpose is front-loaded and every sentence carries routing, resolution, or return-shape information. It is dense and slightly packed (the alternative-tool sentence and the Returns block add bulk), but with no output schema the return enumeration 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?

Given a single-param tool with no output schema, the description fully covers asset resolution, output structure, counting semantics, prerequisite (no open Sequencer), and sibling routing. An agent has everything needed to select and invoke it correctly.

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 baseline is 3, but the description adds meaning beyond the schema's terse 'Name of the target level sequence': the name resolves to the first asset under /Game case-insensitively and how total_track_count is derived. That resolution behavior is non-obvious and valuable.

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 (lists) and resource (tracks of a Level Sequence), plus the exact resolution rule (first asset under /Game whose name matches sequence_name, case-insensitive). It distinguishes itself from three named siblings, so an agent can tell them apart without opening schemas.

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?

Gives explicit routing: 'For flat lists carrying binding_guid use get_sequence_master_tracks; for spawnable/possessable flags use get_sequence_bindings; for one binding use get_binding_tracks.' Each alternative is paired with the condition that selects it, leaving nothing to inference.

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