Vyexa — video link to short clips

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

Adds substantial behavior beyond the annotations: asynchronous job semantics (returns job_id immediately, runs for minutes), the polling contract, the caveat that num_clips is a ceiling not a guarantee, and the billing implication (consumes the account's clip balance). A non-idempotent mutation with openWorldHint is well characterized by this.

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?

Front-loads the core action and output format in the first sentence, then covers async lifecycle, the num_clips caveat, and billing in short clauses. No sentence is 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?

Despite having no output schema, the description states what is returned (job_id) and the next step (poll get_job), and covers cost and duration. For a 14-parameter async job-creation tool this is complete enough to invoke 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?

With 93% schema coverage the schema already documents nearly every parameter, so the baseline is 3. The description adds one genuinely non-obvious semantic — num_clips is a maximum rather than a guaranteed output count — which is not derivable from the schema and prevents a misread of results.

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+resource (cut a video link into vertical 9:16 short clips with burned-in subtitles) and enumerates the supported source platforms. An agent can distinguish it from list_clips/get_options without opening a schema.

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 says the call only starts a job and that the caller must poll get_job until status is "completed" or "partial", which names the follow-up tool and condition. It does not cover when NOT to use this tool (e.g. vs list_clips), so it stops short of full routing guidance.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, and the description adds genuinely new context: the poll cadence, the meaning of each terminal state, and that 'partial' still yields usable clips. It does not describe pagination or behavior for very old/expired jobs, but the value added over the annotations is substantial.

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?

Three short sentences, each load-bearing: identity, return contents, and two operational caveats. The status list is inline rather than padded into prose, and nothing is repeated from the structured fields.

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?

With no output schema, the description must cover return values, and it names status, progress counters, source info, and clips with download_url. The counters' units and the polling stop condition are left implicit, a minor gap for a poll-based job tool.

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 description coverage is 100% and both parameters are documented there, so the schema carries parameter semantics. The description contributes only an implicit reference to job_id's origin, which the schema already states. Baseline 3 applies.

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+resource ('status of a job created with create_clips') and enumerates the full status vocabulary, plus what the response contains. It ties itself explicitly to the create_clips sibling, so an agent can place it in the workflow without opening the schema.

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 concrete operational guidance ('Poll every 10–15 seconds') and explains the ambiguous 'partial' outcome. It stops short of stating when to use this versus list_clips for retrieving finished clips, which is the one plausible overlap among siblings.

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

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

Annotations already establish readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds value beyond that by disclosing it is a one-time prerequisite call and by characterizing the payload ('when to choose' hints and recommendations by content type). It stops short of describing the response structure, but with annotations carrying the safety profile this is solid.

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 tight sentences with no filler, front-loading the resource and value coverage before the imperative usage instruction. Every clause 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 zero-parameter, no-output-schema lookup tool, the description does the necessary work by naming the option sets and the type of guidance returned. A brief note on the returned structure (a flat list vs. value-to-hint mapping) would close the remaining gap, but nothing essential 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?

The tool takes zero parameters, so the baseline of 4 applies. The enumerated categories in the description describe output content rather than inputs, which is a reasonable use of the space but does not add parameter meaning.

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 (List) and resource (styling options), then enumerates the exact value sets it covers (layout, subtitle_style, title_style, font, subtitle_position). It also names the sibling it feeds into, create_clips, so an agent can immediately distinguish it from list_clips or get_job.

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?

Explicit timing and sequencing guidance: 'Call once before create_clips to pick styling.' This tells the agent both when to invoke it in a workflow and why, with the downstream consumer named. No ambiguity about alternatives is left open.

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

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

Annotations already declare readOnlyHint and openWorldHint=false, so safety is covered. Beyond that the description adds two non-obvious traits: the result set is restricted to finished clips only, and fetching each download_url requires the same Bearer key — an auth constraint an agent would otherwise only discover at call time.

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 short sentences with no filler; the response-shape fact comes before the auth caveat. It loses a point only because the opening sentence is a verbless fragment rather than a properly front-loaded statement of the action.

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?

With no output schema, the description compensates by enumerating the returned fields and flagging the per-clip auth requirement. It is close to sufficient for a 2-parameter read tool, though it stays silent on pagination/result limits and on behavior when no clips have finished.

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%, with both job_id and include_subtitles documented in the schema itself, so the baseline is 3. The description's field list describes the response payload rather than adding meaning to either parameter.

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 is a noun phrase ('Only the finished clips of a job') that names the resource and scope, and the enumerated fields (id, title, duration, download_url) make the payload concrete. However it lacks an explicit verb and does no work to separate itself from siblings like get_job or create_clips.

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?

There is no statement of when to call this versus get_job or create_clips, and no conditions or prerequisites. 'Only the finished clips' hints at a filter but never says what to do when clips are still processing or which tool covers the unfinished case.

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