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

With no annotations, the description carries the full behavioral burden. It discloses one important constraint — the 'guarded' framing and the requirement to fetch prior values from timeline.inspect before event mutations. It does not say whether operations are destructive, reversible, undoable, or what permissions/state they require, which is a meaningful gap for a mutating tool.

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; the scope statement comes first and the mutation prerequisite second. It is well front-loaded, though the second sentence covers only one of many action families, leaving the structure slightly lopsided.

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 17-action tool with a nested, undocumented params object, no annotations, and no output schema, the description is far too thin. An agent knows the tool is audio-related and that event mutations need prior values, but not how to populate params for normalization, bus routing, envelope edits, or loudness analysis.

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% and the schema exposes only an opaque free-form 'params' object (additionalProperties: {}), so the real per-action fields are invisible. The description compensates only partially by telling the agent that event mutations need exact event identity plus prior start/length values, but nothing about the 16 other actions' parameters.

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 states a clear domain (VEGAS audio operations) which separates it from video/timeline siblings like vegas_timeline and vegas_effects. However, 'guarded native VEGAS audio operations' is a generic umbrella verb — the actual scope (gain, normalize, buses, envelopes, loudness) is only discoverable by opening the action enum, and no sibling is named as an alternative.

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?

It gives one concrete prerequisite: event mutations need exact event identity and prior start/length values from timeline.inspect. That is genuinely actionable routing guidance. But there is no when-to-use/when-not guidance relative to vegas_timeline or vegas_project, and no signal about which actions are analysis-only versus mutations.

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?

With no annotations, the description carries the full behavioral burden. It discloses what is returned (actions and their safety contract), which is useful, but never states that this is a read-only, side-effect-free operation, nor anything about auth or rate limits.

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?

A single front-loaded sentence with no filler. Every word contributes to identifying the tool's subject and output.

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 and no annotations, so the description is the only source of information. It names the two things returned (actions, safety contract) but leaves the format of that listing and the read-only nature unstated, which is thin support for a tool whose whole value is what it returns.

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 there is nothing for the description to disambiguate; baseline 4 applies. No parameter-related content is missing.

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 a specific resource ('installed VEGAS connector actions and their safety contract'), which reads as a discovery/capability tool and is plausibly distinct from the operational siblings like vegas_render or vegas_project. It does not explicitly name or contrast with any sibling, so an agent must infer that this is the introspection entry point.

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 guidance on when to call this versus the other vegas_* tools, no prerequisites, and no mention of whether it should be consulted before invoking other actions. The intended use as a discovery step is only implied by the word 'capabilities'.

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?

With no annotations, the description carries the full behavioral burden, and it does disclose genuinely useful mutation behavior: exact event identity required, automatic project backup, and an undo step created. It stops short of covering removal side effects, permission/auth needs, or whether list actions are safe, so it is helpful but incomplete for a 15-action mutation tool.

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 tightly written sentences with the purpose front-loaded and the mutation constraint second; nothing is redundant. It is efficient, though the brevity arguably leaves necessary detail out rather than trimming excess.

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 complex tool with 15 enum actions, a nested free-form params object, no output schema, and no annotations, the description covers only the mutation-safety angle. It never explains the event/track/bus action families or what the params object must contain per action, leaving the agent under-equipped for most of the enum.

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 0% and the params object is a free-form bag with additionalProperties and no documented keys. The description adds no parameter-level detail at all; only the vague "inspect or change" phrasing hints at the list_* versus add/remove/set split of the action enum. It does not compensate for the coverage gap.

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?

"Inspect or change VEGAS/OFX event effects" gives a clear verb and resource, and the event-effect focus distinguishes it from render/media/timeline siblings. However, the action enum shows the tool also handles track effects, bus effects, plugin/preset listing, and effect-chain copying, so the stated scope is narrower than the actual one. That understatement makes the purpose only partially accurate.

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 only guidance is the precondition that mutations need exact event identity; there is no when-to-use, no when-not-to-use, and no routing among the 15 actions or toward sibling tools like vegas_timeline. An agent is left to infer which action applies to which object from the enum names alone.

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?

No annotations are provided, so the description carries the full behavioral burden, and it largely fails to. 'Guarded media replacement' hints that replacement is constrained, but the description never says whether 'remove_take' or 'replace_event_media' are destructive or reversible, what permissions are needed, or how failures surface.

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?

A single front-loaded sentence with no filler, covering the resource scope efficiently. For a nine-action polymorphic tool it is arguably too terse, but nothing is wasted.

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?

This is a multi-action tool with a freeform 'params' object, no parameter documentation, and no output schema, so the description is the only place that could explain each action's inputs and effects. It does not, leaving an agent unable to invoke any action beyond 'inspect' or 'list' confidently.

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 0%: the 'action' enum values have no per-action descriptions and 'params' is a freeform object with additionalProperties and no documented shape. The description names resources (bins, image sequences, event takes) that loosely map to four of the nine actions, but leaves the params contract for each action completely unexplained.

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 specific verbs ('inspect and manage') over a clearly named resource domain ('project media, bins, image sequences, event takes'), which is enough to separate it from sibling domains like timeline, audio, and effects. The word 'manage' is broad, but the enumerated resources pin the scope down well.

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 guidance on when to use this tool versus siblings such as vegas_timeline or vegas_project, and no indication of which of the nine actions to pick for a given intent. The agent must infer everything from the enum values alone.

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?

With no annotations, the description carries the full behavioral burden, and it largely fails. 'Change' implies mutation and the set_/clear_ actions are presumably destructive, but nothing states reversibility, required permissions, confirmation behavior, or what 'guarded' actually means — the one unusual term is left undefined and adds ambiguity rather than clarity.

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?

A single clean, front-loaded sentence with no filler, which is maximally concise. However, for a six-action dispatch tool with an opaque nested params object, one sentence is undersized rather than efficiently scoped.

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?

No annotations, no output schema, six enum actions, and an undocumented nested params object. The description does not explain return values (which it would need to, given no output schema), the params structure, or the meaning of 'guarded' — significant gaps against this tool's complexity.

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 0% and the 'params' object is an unconstrained nested object with additionalProperties: {} and no documented shape. The description names the event vs. track distinction, which loosely maps to the enum, but gives no hint about the per-action parameter payload the agent must construct.

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 and resource: 'Inspect and change ... motion keyframes', scoped to event pan/crop motion and video-track motion. An agent can tell this is the motion/keyframe domain rather than project, timeline, or render. It does not name a sibling, but the domain is distinctive enough to be recognizable.

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?

No when-to-use or when-not-to-use guidance is given, and no alternative tool is named. The description does not clarify when to reach for vegas_motion versus vegas_effects or vegas_timeline, so action selection and tool selection are both left to inference.

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?

With no annotations, the description carries the full behavioral burden, and it does disclose one real constraint: mutations require project_path sourced from a prior inspect call, which establishes a safe read-before-write workflow. However, it does not identify which actions mutate, whether undo/redo or backup have side effects, or what happens on a missing/invalid project_path, so disclosure is partial for a 14-action dispatcher.

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 the action inventory front-loaded and the parameter prerequisite immediately after; nothing is padded. It loses a point because the first sentence largely restates the schema's action enum, though grouping those values into categories (transport control, cursor) adds mild recognition value beyond the raw list.

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 dispatch tool with 14 actions, nested free-form params, no annotations, and no output schema, the description is thin: it gives no per-action semantics, no indication of which actions mutate the project, and no return information. The project_path prerequisite is the only substantive detail, so an agent cannot confidently call a given action without opening external documentation.

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 0% and the params object is free-form (additionalProperties: {}), so the description must compensate. It documents exactly one parameter (project_path, including the requirement that it match inspect's return value) but says nothing about the per-action params implied by snapshot, set_cursor, set_settings, set_selection, or insert_time, leaving most of the nested object opaque.

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 names concrete verbs grouped by function (inspect, backup, save, undo/redo, transport control, cursor, snapshot) over an implied project resource, and the tool name plus enum make the project-scope clear. It does not, however, explicitly state how this differs from siblings like vegas_timeline or vegas_status, and it omits three enum actions (inspect_settings, set_settings, set_selection, insert_time) from its summary list, so it is clear but not fully distinguishing.

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 one concrete guideline is a prerequisite: mutating actions need params.project_path exactly as returned by inspect — genuinely useful routing information. But it never states when to prefer this dispatcher over the other seven vegas_* siblings, nor which of the 14 actions count as mutating versus read-only, leaving the agent to infer usage boundaries.

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?

With no annotations, the description carries the full burden and does disclose two useful traits: the render is asynchronous (implying a poll-for-status workflow) and outputs never overwrite existing files (a non-destructive guarantee). It leaves unstated what 'guarded' actually enforces, permission requirements, whether cancel affects already-written output, or timeouts.

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?

A single dense sentence with no filler; the operation list is front-loaded and the non-overwrite guarantee is tacked on where it is most needed. Slightly crowded for four distinct actions, but nothing is wasted.

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 multi-action, asynchronous tool with an opaque nested params object, no annotations and no output schema, the description leaves critical gaps: no polling/status semantics, no param guidance, and no indication of what the guarded or cancel behaviors return. It gives a thin overview but not enough to invoke it confidently.

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 0% and the 'params' property is an opaque free-form object with no documentation of which keys start/status/cancel accept (renderer/template name, output path, etc.). The description only loosely echoes the action enum, so an agent has no basis for populating params correctly.

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 names the resources (renderers/templates) and the four operations (list, start, inspect/status, cancel) that map onto the action enum, so the agent can tell what the tool does. It stops short of distinguishing itself from siblings like vegas_status or vegas_capabilities, which appear to overlap with the 'status' and 'list' behaviors.

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?

It conveys that renders are asynchronous and 'guarded' but gives no when-to-use guidance: nothing says whether to poll with the status action here or with the sibling vegas_status, nor when other render paths should be preferred. The mode selection is left entirely to inference from the enum.

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?

No annotations exist, so the description carries the full behavioral burden. It conveys that the tool targets live instances but says nothing about return contents, whether it is read-only, error behavior when no instance is live, or authentication needs. Only the pid conditionality adds behavioral information.

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, no filler, with the core capability stated first and the parameter caveat second. 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?

With no output schema and no annotations, the description should do more to explain what an instance listing or inspection returns and what state is required for success. It is adequate for invocation but leaves the agent guessing about results and failure modes.

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 has 0% description coverage for vegas_pid (bare integer with exclusiveMinimum 0). The description compensates well by explaining what the pid means and exactly when it should be supplied, which is the key ambiguity for a single optional 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?

Specific verbs (list, inspect) paired with a precise resource: live VEGAS Pro 2026 connector instances. This clearly separates it from siblings like vegas_project or vegas_timeline, which act on editing domains rather than connector discovery.

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 the tool is used to enumerate or inspect live connector instances, and it gives one conditional rule for the parameter (pass vegas_pid only when multiple copies are open). It does not say when to prefer this over siblings or state prerequisites such as VEGAS needing to be running.

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?

With no annotations, the description carries the full burden. It does disclose a genuine, non-obvious behavioral trait: existing-event mutations are guarded by expected_start_seconds/expected_length_seconds (optimistic concurrency) and require an exact project_path. It says nothing about what gets destroyed, return values, or failure behavior for the many destructive actions like delete_event or ripple_delete.

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 with the purpose front-loaded ahead of the guard requirements. Efficient, though 'guarded' could have been replaced with concrete language at no cost to length.

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 34-action tool with no annotations, no output schema, and an untyped params object, the description is far too thin. It omits the action taxonomy, what 'inspect' returns, and batch semantics, leaving an agent unable to invoke most actions correctly from the definition alone.

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% and 'params' is an untyped free-form object, so the description must compensate. It names four required fields for existing-event mutations, which is useful, but leaves the parameter shape of the other 33 actions (inspect, insert_media, add_marker, batch, etc.) entirely undocumented.

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 and resource ('timeline inspection and editing'), which is enough to distinguish it from siblings like vegas_project, vegas_media, and vegas_effects. The word 'guarded' is undefined jargon, but the core purpose is clear.

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?

'Inspect first' gives a sequencing hint for the inspect-before-mutate workflow, and the mutation guard conditions act as prerequisites. However, it never routes the agent among the 34 actions or explains when to use this tool versus a sibling such as vegas_project.

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