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, but it only says that an effect is applied. It omits whether the operation is destructive, what permissions or preconditions apply, whether duplicate effects are allowed, and what happens if an effect name is invalid.

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, front-loaded with the core action and followed by a useful pointer to get-effects-help. No sentence 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 seven-parameter mutation tool with a nested effectSettings object and no annotations, the description is too thin. It does not explain required index semantics, ordering behavior, or failure conditions, relying almost entirely on the schema and leaving behavioral gaps that matter for correct invocation.

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 all seven parameters are already documented in the schema. The description adds only a reliability tip for effect names, which aligns with the schema's own note that effectMatchName is more reliable, and does not decode compIndex, layerIndex, effectSettings, or presetPath beyond the schema.

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 and resource: it applies an effect to a layer. It clearly routes the agent to get-effects-help for reliable effect names but does not distinguish this tool from the sibling apply-effect-template, so it falls short of full sibling differentiation.

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 usage tip, directing the agent to get-effects-help for reliable effect match names. However, it does not say when to use this tool versus apply-effect-template or what conditions make application fail, leaving most usage context implied.

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. 'Apply' implies a mutation, but it does not disclose whether effects are appended or replace existing ones, whether the operation is reversible/undoable, required permissions, or what happens to the template's default settings when customSettings is omitted.

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 tight sentence with no filler. It is front-loaded with the verb and resource, though it is terse to the point of under-specifying a multi-parameter mutation tool.

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 and no annotations, so the description must explain behavior; instead it omits the nested customSettings object entirely, says nothing about the nine template options, and gives no mutation semantics. Inadequate for a 4-parameter mutation tool with a nested object.

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 documents compIndex, layerIndex, templateName (with enum), and customSettings on its own. The description adds no parameter meaning beyond the schema, 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 (Apply) and resource (predefined combination of effects to a layer). The word 'predefined combination' hints that this differs from the sibling apply-effect, which applies a single effect, but it never names that sibling to make the distinction explicit.

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 use this versus apply-effect or the other effect-related siblings (get-effects-help, get-effects-help). The reader must infer that this is the bulk/templated path from the phrase 'predefined combination' alone; there are no stated conditions or 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?

With no annotations, the description carries the full behavioral burden but discloses nothing beyond the basic action. It omits whether After Effects must be running, what happens on duplicate names, side effects on the current project, or return behavior. 'Create' implies mutation but no operational details are given.

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 single sentence is front-loaded, free of filler, and easy to parse. However, for a 7-parameter tool with no annotations it is arguably under-specified rather than optimally concise.

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 tool with 7 parameters, a nested backgroundColor object, and no annotations or output schema, the description is not complete enough. It lacks operational context (project state, permissions, side effects) that an agent needs to invoke it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with every parameter documented (including defaults and value ranges), so the description need not repeat them. The description adds no parameter-level meaning beyond the schema, making the baseline 3 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?

States a specific verb ('Create') and resource ('composition in After Effects'), so the agent knows exactly what the tool does. It does not explicitly contrast with sibling tools, but no sibling performs composition creation, so the purpose is unambiguous.

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, prerequisites, or alternatives (e.g., run-script for custom composition setup). It only restates the action, so an agent gets no help deciding between this and generic scripting tools.

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, yet it says nothing about read-only access, return format, or that the output is a reference list to be fed into the apply-effect tools. The single noun phrase discloses no behavioral traits at all.

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?

It is very short with no wasted clauses, but it is a fragment rather than a complete, front-loaded sentence, and brevity here comes at the cost of substance rather than from efficiency.

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 zero-parameter reference tool this is close to the minimum, but it omits the one thing an agent needs: that it returns a lookup list of effect identifiers/templates used by the apply-effect siblings, and why to choose it over get-help. The definition is too thin even for a low-complexity 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline of 4 applies. No parameter-level semantics are 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?

The description names the resource content ('effect match names and the predefined effect templates') but supplies no verb — it is a noun phrase rather than a statement of what the tool does. It also fails to distinguish itself from the sibling get-help, so an agent cannot tell which help endpoint to call.

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 prerequisites, and no mention of when to prefer this over get-help or how its output relates to apply-effect / apply-effect-template. Usage is only weakly inferable from the 'help' in the name.

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, yet it discloses almost nothing beyond the topic. It doesn't say whether it returns static text or live state, whether it requires a running bridge, or that it's a read-only/non-destructive call.

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 no wasted words, and the topic is front-loaded. It is efficient, though slightly terse given no other fields carry 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 zero-parameter help tool with no output schema, this is minimally adequate: it names the subject matter but omits what is actually returned and how it differs from get-effects-help. With no annotations and no output schema, the description could carry more of that load.

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 for this dimension is 4. There is no parameter semantics for the description to clarify.

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 indicates this is a help/documentation resource about setting up and using the Ibintec After Effects MCP, but it never states a verb (e.g. 'returns documentation') or explicitly distinguishes itself from the sibling get-effects-help. An agent can infer it's a help tool, but the boundary against the other help tool is left unclear.

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 is given: the description doesn't say to call this on setup/configuration questions versus get-effects-help for effect-related questions. Usage is only implied by the topic words 'set up and use'.

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 burden. It usefully discloses a behavioral trait — that results are only worth fetching after a slow/timed-out command — but omits what happens if no result exists, the return format, and any read-only/error 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?

Two short sentences, zero filler, with the core action front-loaded and the gating condition immediately after. Every sentence 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 retrieval tool with no annotations or output schema, the description covers purpose, trigger condition, and source of the data. It could say a bit more about the shape/contents of the returned result, since no output schema exists to carry that.

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 clarify beyond the schema. The baseline of 4 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 ("Read") and resource ("the last result After Effects wrote"), which is clearly distinct from the action-oriented siblings like run-script and apply-effect. It doesn't explicitly name a sibling to differentiate against, but the retrieval-vs-action distinction is self-evident here.

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 a concrete when-to-use condition ("Only needed if a command timed out because it was slow") plus an example (heavy effects), which effectively also states when-not to use it. It does not name a specific alternative tool to check first, so it falls short of a full 5.

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 full behavioral burden. It usefully discloses a hidden side effect that the name would not imply: the test mutates the active composition by applying test effects to it. It does not say whether those effects are cleaned up afterward, whether the change is undoable, or what a pass/fail signal looks like.

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 diagnostic intent front-loaded before the mechanism. There is mild redundancy in restating the word 'test' twice (test command / test effects), but no wasted sentences.

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-argument diagnostic with no output schema and no annotations, the description covers the mechanism but omits the result contract (is there a pass/fail or an error to interpret?) and whether the applied test effects persist in the composition. The sibling get-results suggests output is fetched elsewhere, but that is not stated.

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 and the schema is an empty object with full description coverage, so there is nothing for the description to clarify. The baseline for a parameterless tool 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?

Names a specific action (runs the bridge's test command in After Effects) and its concrete effect (applies test effects to the active composition), so the agent knows exactly what happens. It lacks an explicit contrast with the closely related sibling run-script, which also executes code in After Effects, leaving the boundary between 'test' and arbitrary script execution to inference.

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 lead phrase 'Check the connection' implies the intended scenario: verifying the host bridge is alive. However, it never says when not to use it, whether it is safe to run mid-workflow, or why the agent should pick this over run-script or get-help for diagnostics.

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 real behavioral context: only the enumerated commands exist, units are specified (seconds, pixels, colours 0-1 for layers but 0-255 for composition background), and it flags that dedicated tools use compIndex/layerIndex instead of compName. It does not describe error behavior, reversibility, or the shape of the returned result.

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 purpose and the 'cannot run arbitrary code' caveat are front-loaded, then commands are grouped under Read / Compositions / Layers headings. It is long, but the density is justified by 19 enum values and nested parameter objects; a few inline commands on one line are slightly harder to scan.

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 high-complexity dispatcher with a nested parameters object and no output schema, the description covers usage, commands and units well. The gap is return-value behavior: 'return its result' is the only hint about what the agent gets back from each command.

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% but only nominally ('The command to run', 'Arguments... as listed in the description'), so the description is de facto the only source of parameter structure. It supplies per-command argument names plus meaningful units and ranges (times in seconds, positions in pixels, layer colours 0-1 vs composition background 0-255), which is genuine added value.

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 opening sentence gives a specific verb (run) and resource (the bridge's built-in After Effects commands) and immediately bounds it: 'it cannot run arbitrary code.' It then enumerates every command, so an agent can distinguish this dispatcher from siblings like apply-effect or setLayerKeyframe 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?

It explicitly routes the agent away from this tool for keyframes, expressions and effects ('Prefer the dedicated tools...') and tells it to verify visual changes with view-comp. However, no guidance is given for overlapping siblings such as create-composition, which this tool can also perform via its createComposition command, so the routing is incomplete.

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 disclosure burden. It does not say whether an existing expression is overwritten, whether the bridge/AE instance must be running, whether the change is undoable, or how errors surface for an invalid expression string. For a mutation tool with zero annotation coverage this is a real gap.

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 states the action, the target, and an example, with no filler or 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?

For a 4-parameter mutation tool with no output schema and no annotations, the description covers the core action adequately but omits return behavior and operational prerequisites. It is minimally sufficient rather than 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%, including the "" removal convention and the accepted property names, so the schema does the heavy lifting and 3 is the baseline. The description's wiggle example adds mild illustrative value but no syntax or format detail beyond the schema.

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 (set/remove) and resource (After Effects expression on a layer property), with a concrete example (wiggle(2,20)). It is clearly distinguishable from siblings like setLayerKeyframe and apply-effect, though it never names them to draw the boundary 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?

'Set or remove' implies the two usage modes and the example shows a typical expression, but there is no explicit when-to-use vs alternatives (e.g. setLayerKeyframe for static values) and no prerequisites such as a running After Effects instance or bridge connection.

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. It discloses the animation intent, but says nothing about whether an existing keyframe at that time is overwritten, what permissions or undo state apply, or any side effects of mutating the property.

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, action front-loaded, no redundant or filler text. Every clause 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 5-parameter mutation tool with no annotations and no output schema, the description covers the core action but omits overwrite behavior, error conditions, and return information. Adequate but with clear gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so every parameter including the value-unit conventions is already documented in the schema. The description adds 'at a given time' but no format or semantic detail beyond what the schema provides, 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 (Set) and resource (a keyframe on a layer property) plus the temporal scope, which is enough to separate it from apply-effect or setLayerExpression. It stops short of explicitly contrasting those siblings, so it is not 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?

The second sentence implies usage ('Add two or more keyframes on the same property to animate it'), giving a hint about intent but no explicit when-to-use, prerequisites, or when to prefer an alternative tool such as setLayerExpression.

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 meaningful behavior: the output is one IMAGE containing multiple evenly spaced frames annotated with their times, and it defaults to the active composition. It omits cost/side-effect context such as render latency or whether After Effects must be running, which keeps it short of a 5.

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-loaded with the action ('SEE a composition'), followed by the return format, the usage trigger, and the default. Every sentence earns its place with 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?

For a 6-parameter read tool with full schema coverage and no output schema, the description supplies the missing return-value semantics (single image, frame timestamps) and the default target composition. It leaves minor gaps about rendering cost and environment prerequisites.

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 every parameter is already documented with defaults and bounds, so the baseline is 3. The description only lightly reinforces this by noting the active-composition default (compName) and the evenly spaced frame sampling, adding no new syntax or format detail.

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: renders evenly spaced frames from an After Effects composition and returns a single composite image with per-frame timestamps. This is clearly distinguishable from siblings like create-composition or apply-effect, which mutate the project rather than produce a visual preview.

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 tells the agent when to use it: after building or animating something, to verify text placement, timing and motion before reporting completion. It gives clear context but names no alternatives or exclusions (e.g., when a single-frame preview would be preferable).

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