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

Annotations already declare destructiveHint=true, so the safety warning is present. The description adds only the target-window context and does not disclose prerequisites such as a dialog needing to be open, potential irreversible consequences of clicking, or any confirmation behavior.

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 description is a single, front-loaded sentence with no wasted words. It is appropriately sized for a simple one-parameter UI 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?

For a simple one-parameter action with a fully described schema and destructive annotation, the core is present. However, it lacks differentiation from other UI tools and omits safe-use context that would help an agent invoke it correctly in complex automation flows.

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% and the single "label" parameter is already documented with examples like "Next", "Cancel", "Import", and "OK". The description adds no additional meaning beyond what the schema provides, so the baseline of 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?

The description states a specific verb ("Click") and resource ("button") for Final Cut Pro, with target context of the open dialog or front window. It is clear but does not distinguish this action from sibling UI tools such as fcp_menu_click or fcp_press_keys.

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 parenthetical "(or front window)" implies the tool is for interacting with an open dialog or active window, but there is no explicit when-to-use guidance, no when-not guidance, and no routing to alternative UI-automation 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 declare destructiveHint=true and non-readOnly; the description adds that this is driven through a menu action in the UI, which is useful given the automation-based sibling set. However, it never explains what makes it destructive — e.g. that overwrite can clobber an existing file, or that it requires FCP to be frontmost — leaving the destructive flag unexplained.

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?

One compact sentence with the core action front-loaded and the mechanism trailing. No wasted words, though the single-sentence form forces the when/why guidance to be inferred.

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, disk-writing UI-automation tool with no output schema, the description should at minimum flag the overwrite hazard and the FCP-foreground requirement. It covers the what and roughly the how, but leaves the risk profile under-explained.

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 75%, and the description adds real meaning for two of the four params: '(or browser selection)' explains what focus_timeline toggles between, and 'then read it' ties to read_after. Overwrite and output_path are left to the schema, which is acceptable at this coverage level.

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 (Export) and resource (open timeline / browser selection as FCPXML) plus the underlying mechanism (File > Export XML). It is distinguishable from fcpxml_read (which only reads) and fcpxml_build_timeline, though it doesn't explicitly disambiguate against fcp_share_export.

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?

Implies when to use it (you need an FCPXML dump of the current timeline or browser selection) and the focus_timeline toggle hints at the timeline-vs-browser choice. But there is no explicit when-not, no mention of prerequisites (Final Cut must be running, a project open), and no routing to sibling alternatives.

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, so the safety profile is covered; the description adds the meaningful scoping fact that this returns sequence-level metadata only, not timeline contents. It does not mention whether Final Cut Pro must be running or what happens when the name is ambiguous, but with annotations and an output schema in place the bar is lower.

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 waste, and the core capability is front-loaded before the routing hint. Every clause carries information the agent needs.

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?

The existence of an output schema means return values need not be explained, and the read-only nature is covered by annotations. However, for a lookup tool with two undocumented scoping parameters (event, library), the description leaves a real ambiguity unresolved: whether a bare name is sufficient or whether the project must be disambiguated by library/event.

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 only 33% — just 'name' is documented as exact-match, while 'event' and 'library' have no descriptions at all (default null). The description supplies no parameter guidance whatsoever, not even that event/library narrow the lookup when project names repeat across libraries. With low coverage the description was required to compensate and does not.

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 verb ('Get') plus resource ('project's sequence details') and an explicit enumeration of the returned fields (duration, start, frame rate, timecode format). The second sentence contrasts scope with fcp_export_xml, so an agent can distinguish it from the sibling without opening either 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?

It clearly states the boundary case: for clips, titles and markers, open the project in the timeline and use fcp_export_xml instead. That is an explicit alternative with a condition. It stops short of stating prerequisites (e.g., needing a library/event to disambiguate duplicate project names) or saying when not to use it at all.

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?

Adds genuinely useful behavior beyond annotations: the call blocks ('wait until it responds') and is effectively idempotent via bring-forward. Annotations already declare non-readOnly, non-destructive, non-openWorld, so the remaining burden is low. It doesn't say what happens on timeout or if the app is not installed.

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 short sentence with the action and the completion condition front-loaded; 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?

An output schema exists, so return values need not be explained, and the tool takes no parameters. The only gap is failure/timeout behavior, which is minor for a simple launch 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?

Zero parameters, so per baseline this scores 4. The description correctly implies no configuration is needed.

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 concrete verb and resource ('Open Final Cut Pro'), plus the alternate behavior (bring forward) and the completion condition. It is distinguishable from siblings like fcp_status because it launches rather than queries, though it never names an alternative explicitly.

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 'or bring it forward' phrasing implies it is safe to call whether or not FCP is running, but there is no explicit guidance on when to prefer fcp_status first or what to do if launch fails. Usage is inferable rather than stated.

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?

The annotations already establish that this is a safe read-only operation with openWorldHint=false, so the description does not need to repeat safety claims. It adds useful scope by clarifying that results include events and projects, but it does not describe filtering behavior, performance implications of details, or how "open" libraries are determined.

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 description is a single front-loaded sentence with no wasted words. It states the core action and scope immediately.

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?

The tool has a complete schema, an output schema, and read-only annotations, so the description does not need to explain return values or safety. It conveys the main inventory purpose and nested result shape, but it omits any mention of the optional library/event filters or the slower details behavior.

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%, so the schema already documents the event, details, and library parameters thoroughly. The description adds only a high-level indication that events and projects are included, without explaining the optional filters beyond what the schema provides; baseline 3 is appropriate.

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 gives a specific verb and resource: "List open libraries" and further specifies that each result includes events and projects. This clearly distinguishes it from single-project tools such as fcp_get_project, though it does not explicitly name a sibling 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?

The phrase "List open libraries with their events and projects" implies a discovery or inventory use case, but it does not state when to use this tool instead of alternatives like fcp_get_project or fcpxml_read. There are no exclusions or explicit guidance about prerequisites.

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?

The sentence "Acts on the current selection, like a person clicking it" is genuinely useful behavioral context: it makes clear that the tool does not target a specific item and that its effect depends on the existing selection. However, with destructiveHint=true already declared, the description adds no warning about which actions may be irreversible, and it does not mention focus or authentication requirements.

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, front-loading the verb and resource before the behavioral analogy. Every phrase carries information.

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 one-parameter tool with annotations and no output schema, this is mostly adequate: the selections semantics are covered. Missing are the link to fcp_menu_list for discovering valid paths and any warning tied to its destructive classification, which matters for a UI-automation click.

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%, and the schema already documents the menu-path array with concrete examples such as ["File", "New", "Project"] and the optional "..." segment. The description adds nothing about path construction, so the baseline score of 3 is appropriate.

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 gives a specific verb and resource ("Click a Final Cut Pro menu item"), which tells an agent exactly what the tool does and distinguishes it implicitly from sibling tools that read state or press keys. It stops short of naming the closest alternative, fcp_menu_list, so the boundary is not fully sharp.

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 never states when to reach for this tool instead of fcp_press_keys, fcp_click_button, or fcp_menu_list, nor that the menu path normally comes from fcp_menu_list. It says nothing about preconditions, such as Final Cut Pro being launched or focused.

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, so safety is covered. The description adds non-obvious value by disclosing what the result contains — per-item enabled state and keyboard shortcuts — which tells the agent it can pre-check availability before acting.

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; verb and object come first. It is efficient but leaves no room for the routing hint that would make it more useful.

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?

One optional parameter, no output schema, and the description covers the return shape (enabled state, shortcuts) that the schema cannot. Only the relationship to fcp_menu_click is missing, which is a minor gap for a low-complexity read 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 the path parameter is fully explained there (omit for menu bar, ["File"] for a menu, ["File","Share"] for a submenu). The description adds nothing about the path argument, so 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 (list) and resource (Final Cut Pro menu items) and names the payload fields (enabled state, keyboard shortcuts). It does not distinguish itself from the obvious sibling fcp_menu_click, so an agent must infer the read-vs-act split.

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 guidance, no mention of fcp_menu_click as the alternative for invoking what is listed, and no note on whether a UI snapshot must exist first. The agent gets only implied usage from the verb 'List'.

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 destructiveHint=true and readOnlyHint=false, and the description adds genuinely useful context that the app is focused/brought forward first. However, it never explains the destructiveness risk of sending arbitrary keystrokes (e.g., cmd+z, delete) or what happens on failure, leaving the most important behavioral trait unaddressed.

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?

One short sentence with the key fact front-loaded and no filler. Appropriate size for the tool, though the parenthetical about focus could be integrated more cleanly.

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?

An output schema exists, so return values need no explanation, and the annotations carry the safety profile. Still, for a destructive keystroke-injection tool the description omits failure modes, repeat semantics, and risk of unintended shortcuts — gaps an agent should not have to infer.

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 only 50%: 'combo' is well documented with examples, but 'repeat' (1-100) has no description anywhere. The tool description adds nothing about either parameter, so it fails to compensate for the undocumented repeat multiplier, which meaningfully changes behavior and risk.

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 ('Press a keyboard shortcut in Final Cut Pro'), which is clearly distinct from siblings like fcp_menu_click or fcp_click_button. It also discloses that FCP is brought to the front, a detail not evident from the name alone.

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?

Usage is implied by the verb — an agent can infer this is for keyboard shortcuts versus menu or button clicking — but nothing explicitly states when to prefer it over fcp_menu_click or fcp_click_button, nor any prerequisites (e.g., FCP must 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?

Annotations declare destructiveHint=true and readOnlyHint=false, so the safety profile is already known, but the description adds nothing about the destructive behavior itself. Critically, the overwrite parameter — the thing that determines whether an existing file is clobbered — is never explained anywhere, and failure modes (folder must exist) appear only in the schema.

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?

One sentence, front-loaded with the resource and ending on the confirmation step. Nothing is wasted or padded.

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 file-writing tool with no output schema, the description omits what happens on success or failure, whether the dialog is dismissed, and how overwrite changes behavior. An agent could invoke it and unknowingly overwrite an existing file.

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 67%, with button and output_path documented but overwrite left completely bare. The description's 'folder and file name' merely restates the output_path schema text and gives no meaning to overwrite or button, so it does not compensate for the 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?

The description states a specific verb chain (fill in, then confirm) against a concrete resource (Final Cut Pro's open save dialog), so an agent knows this drives a native UI dialog rather than an export API like fcp_share_export or fcp_export_xml. It stops short of naming a sibling or stating the precondition that the dialog must already be open, which keeps it off a 5.

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?

Usage is only implied: 'Final Cut Pro's open save dialog' hints the dialog must already exist, but there is no explicit when-to-use, no when-not, and no named alternative such as fcp_share_export or fcp_click_button. An agent must infer the prerequisite from the phrasing.

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, so the safety profile is covered and the description needn't repeat it. It adds that the capture targets FCP's visual surface, but says nothing about the return form (inline image vs. file path), size/resolution, or failure behavior when FCP isn't running.

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?

One tight sentence with the purpose front-loaded and zero filler. Slightly clipped given that a screenshot tool's output form is the key operational detail an agent needs.

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 output schema exists, so the description is the only place to state what comes back — it implies a viewable image but never confirms format or whether it is returned inline. For a minimal one-parameter read tool that is adequate, but not complete.

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 the single parameter window_only already documents 'capture just FCP's front window (else the main display)'. The description mentions neither window_only nor its default, so it adds nothing beyond the schema — baseline 3.

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 concrete verb and resource (screenshot of Final Cut Pro) plus what it visually captures — viewer, timeline, dialog. Clear without opening the schema, but it never distinguishes itself from the sibling fcp_ui_snapshot, which plausibly overlaps.

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?

Usage is only implied through the 'so you can see…' rationale; there is no explicit when-to-use statement, no mention of when to prefer fcp_ui_snapshot or fcp_menu_list, and no stated prerequisites (e.g. FCP must be running/frontmost).

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?

Adds genuinely non-schema information: rendering happens in the background and the call returns as soon as the export starts, so agents know not to expect a finished file. However, annotations already flag destructiveHint=true and the description never explains the destruction surface (existing files at output_path, the overwrite flag) or failure modes, which is the highest-value context 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 the core action front-loaded and the async caveat immediately after; nothing is padded. It could be slightly more efficient by merging the File > Share menu path repetition, but the structure serves the reader.

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 usefully clarifies the return semantics (returns once the export has started). Still missing for a destructive, 4-parameter tool: what overwrite does, what focus_timeline controls, and whether the export is safe to call when a destination isn't installed.

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 only 50%: destination and output_path are documented in-schema, while overwrite and focus_timeline have no description anywhere. The phrase 'using that destination's current settings' adds real meaning by telling the agent encoding settings come from the destination rather than parameters, but overwrite (the destructive switch) and focus_timeline remain 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 a specific verb and resource: render the open timeline via File > Share using the destination's current settings. An agent can distinguish it from fcp_export_xml (XML interchange) by the 'Share destination render' framing, though it never explicitly names that sibling.

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 guidance on when to prefer this over fcp_export_xml or fcp_save_dialog, and no exclusions or prerequisites (e.g. whether FCP must be running, whether a timeline must be focused). The only usable signal is the async note, which is about behavior rather than tool selection.

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?

The description is consistent with the readOnlyHint/openWorldHint annotations and adds the diagnostic framing (permissions, helpers) that annotations don't convey. It does not say what the check reports back or what a failure result looks like, and with no output schema that gap matters.

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 the diagnostic scope first and the invocation trigger second – well front-loaded and free of padding. Slight deduction because "permissions and helpers" is vague filler rather than informative phrasing.

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 parameters and no output schema, the description carries the burden of explaining what a status check reveals, and it only gestures at categories (FCP, permissions, helpers). An agent knows when to call it but not what it will learn or how to interpret the result.

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 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?

The description gives a verb ("check") and a resource ("Final Cut Pro, permissions and helpers"), so an agent can tell this is a diagnostic/status tool rather than a media or project operation. But "helpers" is unexplained jargon and the objects being checked are listed vaguely, so the precise purpose is only implied.

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?

"Call this first when something fails" is explicit, actionable guidance on when to invoke the tool, which is unusually good for a status endpoint. It stops short of naming what to do next or which sibling to fall back on for specific failures, but the trigger condition is clear.

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, so the safe read-only profile is covered. The description adds that the return is a structured tree of UI elements, which is useful context, but says nothing about truncation behavior from depth/max_nodes limits or what happens when no window is found.

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 that names the verb, resource, and returned form with zero filler. Nothing in it 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 3-param, no-output-schema read tool, the definition covers the core purpose but leaves return-structure and truncation semantics undocumented. It is minimally adequate but leaves the agent guessing about depth/max_nodes effects.

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 only 33% — the 'window' parameter is documented in-schema and the description's 'open dialog or front window' echoes it, but 'depth' and 'max_nodes' (with truncation implications) get no explanation in either structured fields or description. The description 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?

States a specific verb ('Describe') and a precise resource ('UI of the open dialog or front window... as a tree') with examples of what it reports (buttons, fields, values). This distinguishes it from visual siblings like fcp_screenshot, though it doesn't name any sibling explicitly.

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 phrase 'open dialog or front window' implies the inspection context, but there is no explicit when-to-use or when-to-prefer-alternatives guidance versus fcp_screenshot, fcp_menu_list, or fcp_status. Usage must be inferred from the resource named.

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 declare a non-read-only but non-destructive write, and the description's 'save a new file' is consistent with destructiveHint=false and adds the useful detail that the source XML is not overwritten. However, it says nothing about whether Final Cut Pro must be running, what happens when import_into_fcp creates a duplicate project, or about failure modes on invalid timecode.

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?

One compact sentence, front-loaded with the action and resource. Efficient, though the terse single clause leaves no room to front-load the non-obvious 'new file' semantics before the object.

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 six-parameter, file-transforming tool with no output schema and moderate schema coverage, the description covers the core action but omits the file-based workflow context (source XML in, new XML out, optional re-import into FCP) that an agent needs to chain it correctly after an export.

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 83%, so titles, defaults and descriptions already document path, library, output_path, project_name, and the MarkerSpec fields. The description adds no meaning beyond that — it does not even mention that markers is a list accepting mixed kinds or how 'at' is interpreted within the project timeline.

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 verb (add) plus resource (markers/to-dos/chapter markers) and the object it mutates (a project in an FCPXML file), plus the key outcome 'save a new file'. It is clear what the tool does, though it never contrasts itself with sibling file-level tools such as fcpxml_build_timeline or fcpxml_import.

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 gives no when-to-use guidance, no prerequisites, and no alternatives. An agent must infer from the schema that the input comes from fcp_export_xml and must guess whether to use this versus fcpxml_build_timeline or fcpxml_import.

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 declare readOnlyHint=false and destructiveHint=false, consistent with 'create a new project' and 'import it' — no contradiction. The description adds that an .fcpxml is written to disk and opened in FCP, which is useful context, but it is silent on what happens if a project of that name already exists, whether the write overwrites output_path, or what occurs when no library is open.

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?

One purpose sentence followed by two labeled examples, with no filler. The core action is front-loaded before the illustrative payloads.

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 13-parameter tool that mutates disk and drives a desktop app, the description covers intent and item shapes but omits collision/overwrite behavior, the FCP-must-be-running prerequisite, and any failure modes. The rich per-parameter schema carries most of the load, but the description leaves gaps around side effects.

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%, so the baseline is 3, but the two worked examples go beyond the schema by showing how StoryItem and ConnectedItem compose into a real timeline (source_in + duration on the primary, at + lane -1 for music underneath). They clarify ordering and lane semantics in a way the JSON schema alone does not.

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 chain: create an FCP project, serialize it as FCPXML, and import it. That distinguishes it in substance from fcpxml_import (which takes an existing file), but the description never names the sibling, so the agent must infer the boundary.

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?

Usage is implied by the examples of primary and connected item shapes, which show what this tool is for. However, there is no explicit when-to-use guidance versus fcpxml_import, fcpxml_validate, or fcpxml_add_markers, and no stated prerequisite that FCP 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?

Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds meaningful behavioral context beyond the annotations: imports are additive, projects are added, and nothing is overwritten. It does not state prerequisites such as whether FCP must already be running, which would be the remaining useful detail.

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 zero waste. The primary action is front-loaded, and the non-destructive guarantee follows immediately.

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 two-parameter import tool with fully documented parameters and annotations covering safety, the description is largely complete: it explains what the tool does and confirms the operation is additive. It could be slightly stronger by noting whether Final Cut Pro must be running or by pointing to validation as a prerequisite, 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?

Schema description coverage is 100%, and the schema already explains that path is a .fcpxml file or .fcpxmld bundle and documents library defaults. The description adds no parameter-level detail beyond the schema, so the 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?

The description states a specific verb (Import) and resource (FCPXML file or bundle) plus the target application (Final Cut Pro), and it distinguishes itself from siblings like fcpxml_read, fcpxml_validate, and fcpxml_build_timeline by describing an actual import into FCP.

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?

Usage is implied — an agent should call this when it has an FCPXML to bring into Final Cut Pro — but there is no explicit when-to-use/when-not guidance and no reference to alternatives such as fcpxml_validate before importing or fcpxml_read for inspection.

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, so safety and locality are covered structurally. The description adds the useful fact that this is a summary/extraction of a file's contents rather than a mutation. However, it promises 'every clip' while the schema defaults max_items to 400, and it says nothing about how truncation, missing media, or malformed XML are reported.

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 that front-loads the resource and then lists the returned sections, with no filler. It could be tightened slightly by splitting the enumeration, 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?

With no output schema, the description does the right thing by enumerating the returned sections, which is the main completeness requirement here. Still missing: what a caller gets when the file is invalid or partially truncated, and how this differs from adjacent inspection tools.

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%, including the .fcpxmld bundle alternative and the max_items cap semantics, so the description is not required to carry parameter detail. It mentions none of it, and the word 'every' arguably undercuts the max_items behavior documented only in the schema. Baseline 3.

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 gives a specific verb (summarise) and resource (an FCPXML) and enumerates exactly what the summary contains: projects, clips/titles/gaps with timeline position and lane, markers, media. That is concrete enough for an agent to know what comes back. It never distinguishes itself from siblings such as fcp_get_project (live app) or fcpxml_validate (checks the same file), so it stops short of a 5.

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 choose this over fcp_get_project for inspecting a project, or over fcpxml_validate for checking an XML. An agent must infer 'this reads a file on disk, not the running app' purely from the name prefix. No prerequisites or exclusions are given.

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, so safety is covered. The description adds real value by specifying that validation is against the DTD bundled with the installed Final Cut Pro, which tells the agent the check is local and version-dependent rather than against a fixed online schema.

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 well-formed sentence with no filler, and the key differentiator (which DTD) is front-loaded. It is appropriately sized, though it leaves little room for the usage guidance an agent would benefit from.

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 simple read-only tool with full schema coverage and no output schema, the description covers the essentials but omits what happens on failure — whether errors are returned as messages, line numbers, or a boolean. That reporting behavior is the main thing an agent needs and would have to discover by calling.

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 one parameter at 100% schema description coverage, the schema already explains that 'path' accepts a .fcpxml file or .fcpxmld bundle. The description adds nothing about the path beyond that, so the baseline of 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 and resource ('Check an FCPXML file') plus the validation reference (the DTD bundled with the installed Final Cut Pro), which makes it clearly distinct from sibling tools like fcpxml_read, fcpxml_import, and fcpxml_build_timeline. No sibling is named explicitly, so it stops short of a 5.

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?

Use case is implied — you'd validate before reading or importing an FCPXML — but the description never says when to call this versus fcpxml_read or fcpxml_import, nor any preconditions. No explicit exclusions or alternatives are offered.

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, so the safety profile is covered. The description adds that this is a metadata-extraction operation over listed attributes, but says nothing about behavior on missing/unsupported files or whether paths must be local — useful context that is missing.

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 naming the verb first and then the value list. No filler, no redundancy.

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?

An output schema exists, so return-value explanation is unnecessary, and the description names the fields an agent would care about. Minor gaps remain around accepted file types and failure behavior, but for a one-parameter read-only probe this is nearly sufficient.

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?

Only one parameter and schema description coverage is 100%, so the schema already documents 'paths' as 'Media files to inspect.' The description's phrase 'media files' mirrors the schema without adding format, count, or local-path semantics beyond it, so 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 ('inspect') and resource ('media files') and enumerates the returned attributes (duration, resolution, frame rate, timecode, audio), which is concrete and distinguishable from the FCP editing/UI siblings. It does not explicitly name or contrast with any sibling, so it stops short of a 5.

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 when-to-use guidance, no prerequisite (e.g. files must be locally accessible), and no mention of alternatives or follow-up tools such as fcpxml_read or fcp_get_project. The agent must infer the call context entirely.

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