after-effects-mcp
Server Quality Checklist
Latest release: v0.1.0
- Disambiguation4/5
Most tools target a clear resource-action pair, and the high-level workflow tools are distinguished by their descriptions (silence-based cuts vs. transcript-based cuts, blueprint validation vs. audit vs. repair). A few pairs like ae_capture_frame/ae_capture_frames and ae_build_smart_edit/ae_build_youtube_edit could be momentarily confused, but their stated purposes are ultimately distinct.
Naming Consistency4/5The tool names consistently use the ae_ prefix, snake_case, and mostly follow a verb_noun pattern such as list_compositions, create_layer, render_composition, and decide_review. Minor deviations like ae_health, ae_reconnect, ae_search, and ae_run_jsx break the strict pattern but do not create significant confusion.
Tool Count2/5With 48 tools, this server is well past the 25+ threshold for a heavy tool count. The breadth is understandable given the mix of low-level AE operations, editorial planning, review workflows, and Blender integration, but the aggregate surface creates real agent selection overhead and would benefit from modular splitting.
Completeness4/5The server covers the main After Effects lifecycle well: compositions, layers, effects, keyframes, expressions, rendering, reviews, and high-level motion/editorial workflows. Minor gaps exist, such as no direct tool for updating text layer content, renaming/deleting compositions, or reordering effects, but the ae_run_jsx escape hatch mitigates these.
Average 3.6/5 across 48 of 48 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 7 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add
glama.jsonto the root of your repository:{ "$schema": "https://glama.ai/mcp/schemas/server.json", "maintainers": [ "your-github-username" ] }Then . Browse examples.
Add related servers to improve discoverability.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral disclosure burden, but it only says a motion graphic is created. It does not disclose whether a new composition is created or an existing one is modified, what side effects occur, whether the operation is destructive, or what state must already exist for the tool to work.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single tight sentence with the verb front-loaded and no fluff. It is concise, but the brevity leaves out important context that would normally be expected for a complex tool with nine parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with nine parameters, no annotations, and no output schema, this one-sentence description is far from sufficient for an agent to invoke it correctly. It omits required input semantics, composition-target guidance, side effects, and any indication of what the tool returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, with only template_id, comp_name, and comp_index documented in the schema. The tool description adds nothing about the six undocumented parameters (start, end, text, title, subtitle, font_size), and it does not even clarify that template_id is required or how it relates to 'brand-aware' behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
States a concrete action ('create') and a specific resource ('reusable, brand-aware motion graphic') with a location ('directly in an After Effects composition'). It is distinguishable from siblings like ae_create_motion_blueprint and ae_build_motion_video, though it does not explicitly say 'template' or clarify the exact relationship between a motion graphic and a motion template.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 provided. The description does not mention the prerequisite of selecting a template via ae_list_motion_templates, nor does it contrast this tool with ae_create_motion_blueprint or ae_build_motion_video, so the agent must infer usage from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states that properties are set on a layer, but does not disclose whether unspecified properties are left untouched, whether this overwrites existing transforms, whether timing values are in seconds or frames, or whether any destructive side effects occur. The brief property list gives no insight into the operation's actual behavior beyond the fact that it mutates layer properties.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. The verb and resource are stated first, followed by compact parameter examples. It could be slightly more structured by explicitly grouping timing parameters, but it remains appropriately sized and efficient for its purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a 15-parameter mutation tool with no annotations and no output schema, so the description should provide substantial context. It only covers a subset of property units and omits how to identify the target layer/composition, whether partial updates are supported, what happens to unspecified properties, and the exact behavior of timing fields. The description is too sparse for an agent to reliably invoke this tool correctly in ambiguous cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds useful meaning for a few parameters: position is [x,y], scale is [x,y] percent, rotation is in degrees, and opacity is 0-100. However, schema description coverage is only 27%, and most parameters (name, enabled, inPoint, outPoint, startTime, parent_name, threeDLayer, comp_name, comp_index, layer_name, layer_index) are not meaningfully explained in the description. The 'timing' category is mentioned but not tied to inPoint/outPoint/startTime, so an agent is left to guess key units and semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Set transform/timing/name/parent on a layer.' It lists the main property categories and gives examples (position, scale, rotation, opacity), making the tool's purpose reasonably clear. It doesn't explicitly differentiate from sibling tools like ae_set_keyframes or ae_set_expression, but the resource and categories are concrete enough to avoid major confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives. For example, an agent cannot tell from the description whether to use this tool or ae_set_keyframes for timing-related changes, or how this relates to ae_create_layer or ae_get_layer. The description implies a use case but provides no explicit context, exclusions, or alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must carry the full burden of behavioral disclosure. It confirms a write operation but does not say whether settings persist, whether they merge with existing preferences, what they affect, or whether any preconditions exist. This is a significant gap for a 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
One tight sentence, front-loaded with the verb and resource, and free of filler. It is concise, though the brevity comes at the cost of detail needed for a 9-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For 9 optional parameters, no annotations, and no output schema, a single generic sentence is incomplete. It does not cover defaults, merge/persistence behavior, valid value context, or what happens after setting preferences.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only groups parameters into two broad buckets without mapping to the 9 fields or clarifying value semantics. It fails to compensate for the undocumented schema, leaving agents to infer meaning from enums and names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Set') and a distinct resource ('workflow preferences'), and scopes it to autonomous/approval workflow behavior plus project brand defaults. It does not explicitly compare with ae_get_workflow_preferences, but the resource is identifiable enough to separate it from sibling editing tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus ae_get_workflow_preferences or other workflow-related tools. The phrase 'high-level editing workflows' implies a context but provides no decision rule or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It reveals that setting is by effect_name or effect_index and that indexing is 1-based, but it does not disclose side effects, failure modes, whether values are overwritten, or what context (comp/layer) is required.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the core action. Every sentence contributes, but it is slightly thin given the tool's 8 parameters and mutation semantics.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a mutation tool with 8 parameters, no annotations, and no output schema, yet the description provides almost no operational context. It omits how comp_name/comp_index and layer_name/layer_index relate to locating the effect, what happens if the effect is not found, and whether property values must match a specific type. The 1-based effect identification note is helpful but far from sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 63%, and the description adds a small but useful detail: effect identification via effect_name or effect_index with 1-based indexing. The schema already documents many parameters with descriptions, so the description does not need to repeat them. Some parameters remain undocumented in the schema and description, keeping this at baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb and resource: 'Set a property on an effect instance.' It also explains how the effect is identified. However, it does not explicitly differentiate itself from siblings like ae_apply_effect, though 'effect instance' strongly implies an existing effect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not say when to prefer this tool over ae_apply_effect or ae_remove_effect, nor does it mention prerequisites such as the need for an existing effect or how to discover valid properties.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden, and it does disclose the important non-mutating behavior: 'without mutating After Effects.' It also hints at output style with 'explainable coherence checks,' but it does not explain what the checks actually inspect, whether a connection is required, or what happens on failure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one tight sentence that front-loads the core action, names the resource, and adds the critical safety qualifier. There is no redundant or filler language.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 1-parameter tool with an open-ended object schema, no output schema, and no annotations, this description is too minimal. Missing context includes what the returned 'explainable' results look like, prerequisites, and how this validation differs from the audit and repair siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has a single 'blueprint' object with 0% description coverage, so the description must compensate. It confirms the tool operates on a 'motion blueprint,' which names the parameter, but it does not clarify the required internal structure of that blueprint or what properties are expected for validation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb-resource pair: 'Run explainable coherence checks on a motion blueprint' and adds the key non-mutation qualifier 'without mutating After Effects.' It clearly distinguishes itself from mutation-oriented siblings like ae_repair_motion_blueprint, though it does not contrast with the similarly named ae_audit_motion_coverage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to choose this tool over siblings such as ae_audit_motion_coverage or ae_repair_motion_blueprint. The 'without mutating' phrase implies a safe validation use case, but there are no when-to-use or when-not-to-use instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full behavioral disclosure burden. It reveals that an automatic export preset is used and that output requires visual review, but it omits other important behavior such as file output, overwrite effects, or whether rendering is synchronous.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, front-loads the core action, and adds an important caveat without waste. However, it is so brief that valuable behavioral and usage context is missing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with five parameters, no output schema, and no annotations, the description is incomplete. It doesn't explain what parameters are needed to target a composition, where output goes, what the result looks like, or whether rendering is safe to run repeatedly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 40%, so the description should compensate for unclear parameters like output_path, output_preset, and format. It only hints at output behavior through 'automatic export preset' and does not clarify parameter roles or relationships.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the operation ('Render a composition') and the specific resource type, with the qualifier 'automatic export preset' adding useful scope. It doesn't explicitly distinguish from frame-capture siblings like ae_capture_frame, but the verb 'render' and reference to export presets make the intent reasonably clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a meaningful usage condition: the render must be visually reviewed before delivery. This communicates when the output is not appropriate for final unattended delivery, though it doesn't explicitly name alternatives or state when to prefer a different tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only describes the act of applying an effect and the accepted name formats; it does not explain default targets, side effects, behavior on existing effects, or error conditions. This is minimal disclosure for an operation that modifies a layer.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the action and immediately provides the key input constraint with relevant examples. Every element earns its place, and there is no redundancy with the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with five parameters, no annotations, no output schema, and optional target selectors, the description is too thin. It does not explain what happens when comp_name/layer_name are omitted, whether an active selection is used, or how the effect is applied, leaving an agent uncertain about correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds slightly beyond the schema by clarifying that the effect accepts both display names and matchNames and giving examples, but it adds nothing about the optional comp/layer precedence or how selection works, which the schema also leaves unstated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Apply') and resource ('an effect'), and specifies the two valid identifier forms: display name or matchName, with concrete examples. This makes the tool's purpose immediately clear and distinguishes it from siblings like ae_remove_effect or ae_set_effect_property.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to prefer this tool over alternatives, when not to use it, or how target layer/composition selection works. It implies usage through the verb 'apply' but provides no context about prerequisites or selection order among the optional comp/layer parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose side effects itself. It does enumerate several significant behaviors: it can repair a blueprint, build scenes, capture QA frames, render output, and create an approval review. Missing are important operational details like whether it overwrites existing compositions, requires After Effects to be running, writes files to output_path, or whether the workflow is repeatable or destructive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence that uses a colon to enumerate the pipeline steps. There is no filler, repetition, or irrelevant detail, and every phrase maps to a distinct workflow stage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a complex orchestrator with 14 parameters, no output schema, and no annotations, the description remains a high-level summary. It lacks guidance on which parameters are needed for a minimal valid run, what 'deterministic named scenes' means for the scenes array, what happens after the review is created, and what the return value or artifacts will be. An agent would likely need to probe the tool or rely on external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 14 parameters but only 7% description coverage, so the description must compensate for the missing parameter meaning. It maps only a few concepts (blueprint, scenes, render) and says nothing about crucial parameters such as energy, duration, frame_rate, visual_style, aspect_ratio, approved, or output_path. This is insufficient for an agent to confidently construct a correct call.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific resource ('motion-graphics workflow' in After Effects) and a concrete process: validate/repair, build scenes, capture QA frames, render, and create a review. This distinguishes it from the many low-level sibling tools like ae_create_composition or ae_render_composition, though it doesn't explicitly frame itself as an alternative to chaining those tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
'One-shot' clearly implies this tool should be used when the agent wants the entire motion-graphics pipeline completed in a single call rather than using individual sibling tools. However, it provides no explicit when-to-use vs. when-not-to-use guidance and doesn't name any alternatives or conditions where a caller should prefer the atomic tools instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It usefully reveals that approval mode returns an editorial plan until approved=true and that autonomous mode builds immediately. However, it does not disclose mutation side effects, required project state, or what happens to existing After Effects compositions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences front-load the core action, then add behavior and mode options. Every sentence earns its place, and there is no redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 9 parameters, low schema coverage, no output schema, and no annotations, the description is too thin. It leaves out how inputs are resolved, what output is returned, and what prerequisites are needed before building, making it insufficient for reliable autonomous invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low (33%), so the description must compensate. It mentions transcript and the three modes, and it references approval flow, but it does not explain important parameters like comp_name, frameRate, footage_name, transcript_path, or the relationship between transcript and transcript_path. Most parameter meaning is left undefined.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description names a clear action ('Analyze a transcript and optionally build a YouTube edit in After Effects') with a specific resource and platform. It is understandable on its own, but it does not distinguish itself from closely related sibling tools like ae_build_smart_edit or ae_create_editorial_plan.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains approval mode versus autonomous mode and says to use clean, retention, or story mode, which gives context for how to run the tool. However, it does not specify when to prefer this tool over alternative build/planning tools, nor does it give exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden. 'Remove' implies a mutating operation, but the description doesn't disclose what happens on a missing effect, whether removal is reversible, or what state changes are made to the layer.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that front-loads the core action and selection method without any filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With six parameters, none required, and no annotations or output schema, the description leaves critical gaps: how to identify the composition and layer, whether both name and index forms are alternatives, and what a successful removal returns. An agent would need to infer standard patterns from sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67%, and the description adds meaning to the two undocumented parameters (effect_name, effect_index) by presenting them as the selection keys. However, it doesn't clarify whether both can be used together or how they relate to comp/layer parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('remove'), the resource ('an effect'), and the location ('from a layer'), plus the two selection methods (effect_name or effect_index). This distinguishes it from siblings like ae_apply_effect and ae_set_effect_property.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to prefer this tool over alternatives such as ae_list_effects or ae_set_effect_property. It also doesn't explain selection strategy between effect_name and effect_index, or mention required composition/layer identifiers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It says the tool sets keyframes but does not disclose whether existing keyframes are replaced or appended, whether missing properties are created, or what happens with invalid property paths—important side-effect information 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler: the action is front-loaded, the property alias list is compact and useful, and the keyframe format is summarized efficiently. Every segment earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Combined with the schema, the description covers the essential invocation details: property paths, keyframe format, and comp/layer identification. However, it omits behavior around existing keyframes and does not clarify precedence or fallback when neither comp_name nor comp_index is provided, leaving a moderate gap for an autonomous agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is high, so the baseline is 3. The description adds meaningful semantics beyond the schema by specifying that time is in seconds, giving canonical property path aliases like Transform/Position, and summarizing the keyframe object shape in a compact form.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Set keyframes') and target ('layer property'), and it gives concrete property path examples. It does not explicitly differentiate itself from sibling setter tools like ae_set_layer_properties or ae_set_expression, so it falls just 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.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus the many sibling setter/keyframe-related tools. The description explains mechanics such as path aliases and keyframe format, but it never states preferred scenarios, exclusions, or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior, but it only restates the core operation. It does not mention whether the duplicate preserves effects, expressions, or keyframes, where the copy is inserted, or whether any existing selection changes. This is a meaningful gap for a 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no filler. The primary action is front-loaded, and the optional parameter behavior is attached logically.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple operation, the description plus schema is minimally adequate. However, there is no output schema and no mention of how to identify the target layer beyond the schema's own field descriptions, and no explanation of what happens if neither layer_name nor layer_index is provided. This leaves some ambiguity for an agent deciding how to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 80%, so most parameters are already documented. The description adds minor value by clarifying that new_name is used to rename the copied layer. However, it does not clarify the relationship between comp_name/comp_index or layer_name/layer_index beyond what the schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Duplicate') and resource ('layer'), with a clear optional outcome ('optionally rename the copy'). This clearly differentiates it from sibling tools like ae_create_layer or ae_delete_layer without needing to open the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives, nor any mention of when it would be more appropriate to use ae_create_layer or other layer-management tools. The optional-rename note hints at one use case, but it does not provide practical selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does add useful behavioral details: 'deterministic,' 'safe,' and the return of a before/after audit. However, it does not disclose whether the blueprint is mutated in place, what side effects occur, or what the audit contains, so transparency remains partial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the action, scope, and output without wasted words. Every phrase earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description gives the essential action and result but omits details like whether the input is modified in place and what the returned audit contains. It is acceptable but not fully self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only a bare 'blueprint' object with no property documentation (0% coverage). The description partially compensates by naming the relevant dimensions—scene timing, template ids, and graphic text limits—but it does not describe the object shape or any additional semantics needed to construct the input.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action—applying deterministic safe repairs to scene timing, template ids, and graphic text limits—and names the output as a before/after coherence audit. This is a specific verb+resource+scope, though it does not explicitly differentiate itself from sibling tools like ae_validate_motion_blueprint or ae_audit_motion_coverage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when this tool should be used versus alternatives, nor any mention of prerequisites such as running validation or audit first. The intended workflow position is implied by the tool names but never stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It usefully states that the tool 'does not mutate After Effects,' which is an important non-mutating trait. However, it does not explain what the tool returns, whether the blueprint is persisted, how the `brief` is used, or what 'explainable' means operationally for subsequent validation and rendering steps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences and front-loads the core purpose before adding the non-mutation qualifier. It is concise and avoids most filler, though the terms 'canonical' and 'explainable' are slightly abstract and could be replaced with more concrete behavioral details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex creation tool with 10 parameters, a nested scenes array, and no output schema, yet the description offers only a high-level summary. It does not explain what the blueprint output looks like, how to validate it, or how parameters like `energy`, `scenes`, and `render_format` contribute. An agent would likely need external knowledge or further exploration to invoke it correctly and confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it provides no parameter-level explanations. The phrase 'scenes, brand, timing, templates, QA, and rendering' loosely maps to fields like scenes, visual_style, duration, templateId, and render_format, but it does not clarify the `brief`, `energy`, `frame_rate`, or the nested scene structure. This is insufficient for a 10-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Create a canonical, explainable motion-graphics video blueprint.' It further clarifies that creation does not mutate After Effects, which helps distinguish it from sibling creation tools like ae_create_composition. The phrase 'shared source of truth' reinforces the tool's planning-stage purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for generating a blueprint before actual After Effects work, especially through 'without mutating After Effects' and 'shared source of truth.' However, it does not explicitly state when to choose this tool over related siblings such as ae_validate_motion_blueprint, ae_repair_motion_blueprint, or ae_build_motion_video, nor does it mention any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry behavioral disclosure. It says 'Create a saved review item' but doesn't explain side effects, persistence, whether files are written, what record is created, or what happens on failure. The agent is left guessing about the tool's impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no filler. The core action and object are front-loaded, and the approval-mode context is added as a separate clause. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters, nested objects, no output schema, and no annotations, this description is too thin. It omits return behavior, the purpose of plan_path, and any operational caveats. An agent would need the schema and sibling context to use it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25%, so the description must compensate. It clarifies that 'frames' are preview frames and 'render' is optional render metadata, which adds value. However, 'plan_path' is completely unexplained and 'comp' only gets a one-word schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Create') and resource ('saved review item'), and specifies content ('preview frames and optional render metadata'). It is distinguishable from siblings like ae_list_reviews and ae_decide_review, though it doesn't explicitly name them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
'Approval mode should use this before final delivery' provides clear situational context and implies the tool belongs early in the review/approval workflow. It does not state exclusions or name alternatives, but the context is enough to route an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It communicates the decision action and notes, but does not disclose side effects, whether the decision can be changed, permission requirements, or what happens to the saved review item after the call.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action and resource. Every word contributes meaning, with no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple three-parameter tool, the description captures the essential action, but it lacks context about return values, side effects, or prerequisites. Since there is no output schema and no annotations, a bit more behavioral context would be needed to make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only mentions 'notes' without elaborating on review_id or decision semantics. While the parameter names and enum are self-explanatory, the description adds little meaning beyond the schema structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verbs 'Approve or reject' with the resource 'saved preview review item,' making the tool's action and target clear. This clearly differentiates it from sibling tools like ae_create_review and ae_list_reviews, which handle creation and listing rather than decision-making.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The word 'saved' implies the review item already exists, which suggests this tool is used after ae_create_review, but no explicit when-to-use or when-not-to-use guidance is provided. It does not name alternative tools or conditions, leaving usage largely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. 'Get' indicates a read operation, and 'response_format=detailed for layer list' discloses a behavioral distinction between formats. It does not mention potential errors, precedence rules, or whether the tool falls back to an active composition, but it is not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with the primary purpose front-loaded. The response_format instruction is placed second and earns its place. It is concise without padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only getter, the description covers the main purpose and a key parameter behavior. However, with no output schema and no annotations, it does not describe return structure, and the optionality of all parameters leaves the no-argument case unexplained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67%, between thresholds, so the description is not required to fully compensate. It adds meaning for response_format by stating that detailed returns the layer list, which the schema lacks. It adds nothing beyond the schema for comp_name/comp_index and leaves the no-argument default ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description names a clear action and scope: 'Get composition settings and layer index.' It is specific enough to distinguish from ae_get_layer and ae_list_compositions, though it does not explicitly name those siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides one useful usage condition: 'Use response_format=detailed for layer list.' However, it offers no guidance on when to prefer this tool over ae_get_layer or ae_list_compositions, and it does not explain what happens when neither comp_name nor comp_index is supplied (both are optional).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. It communicates the core import operation and project mutation, but does not mention side effects, unsupported formats, path-resolution errors, duplicate handling, or return behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
One compact sentence with no filler; it front-loads the action and resource and includes the essential input constraint. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter, low-complexity tool with full schema coverage, the description covers what is imported, where it comes from, and the target project. It is mostly complete for invoking the tool, though behavioral details absent from annotations (error behavior, return value) would make it fully robust.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%; both the schema and description identify 'path' as an absolute path to a media file. The description adds no extra 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.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description names the specific action ('Import'), the resource ('video/image/audio file'), and the target context ('into the AE project'), plus the input source ('from an absolute path'). This clearly differentiates it from sibling tools like applying effects or rendering compositions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no when-to-use or when-not-to-use guidance, and it does not name alternative tools (e.g., ae_run_jsx) or prerequisites such as an active AE project. The agent must infer that this tool is the right one for standard media import.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. The verb 'check' implies a read-only inspection, and the criteria define what is evaluated. However, it does not disclose side effects, return shape, failure behavior, or whether the audit modifies the blueprint in any way.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, dense sentence communicates the tool's exact purpose without filler. Every clause contributes meaningful audit criteria, making this both concise and attention-effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description fully explains what is being checked, which is the core need for invoking this tool. However, with no output schema and no annotations, it omits what the caller receives back, such as a boolean, a list of findings, or an audit report. It also lacks workflow placement guidance relative to sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage and only a generic object parameter named 'blueprint'. The description clarifies that the parameter is a motion blueprint, which adds some domain meaning. Still, it does not explain the expected structure, required fields, or relationship to blueprints produced by sibling tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Check whether'), a specific resource ('a motion blueprint'), and precise evaluation criteria (object choreography, impact beats, scene variation, readable settle moments). This clearly separates it from siblings like ae_validate_motion_blueprint or ae_repair_motion_blueprint.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. Sibling tools such as ae_validate_motion_blueprint, ae_repair_motion_blueprint, and ae_create_motion_blueprint suggest related workflows, but the description does not state when auditing coverage is appropriate or when another tool should be used instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the return of a frame manifest but does not disclose side effects such as whether frames are written to disk, how many frames are captured in practice, or any failure behavior. For a tool that captures and potentially persists frames, this is a notable gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no filler. It communicates the action, scope, purpose, and return value efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The parameters are well-covered by the schema, and the description states the output is a manifest, but with no output schema and no annotations, an agent still lacks details about what the manifest contains or what happens to the captured frames. The description is adequate for a simple call but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters. The description adds only the 'multiple' framing and does not clarify semantics beyond what the schema provides, which matches the baseline expectation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('capture'), a clear resource ('multiple composition frames'), a purpose ('visual QA'), and an explicit result ('return a frame manifest'). It also distinguishes itself from the singular sibling ae_capture_frame by emphasizing multiple frames, so an agent can tell them apart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'multiple composition frames' implies this is for batch capture, and the sibling ae_capture_frame likely handles single frames, but the description never explicitly names an alternative or states when not to use this tool. Usage context is implied rather than spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. 'Get layer details' clearly implies a read-only operation and lists the information categories returned, which is useful. However, it does not mention failure behavior, ambiguity handling beyond the brief index fallback, or what 'concise' versus 'detailed' actually changes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with no filler. The main purpose is front-loaded, and the only added guidance earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no required parameters and no output schema, the description covers what is returned and the key selection precedence. The response_format parameter is underspecified semantically, but the schema enum values 'concise' and 'detailed' provide enough surface meaning.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 80%, so the baseline is already adequate. The description adds a useful decision rule—prefer layer_name and fall back to layer_index when names collide—which clarifies intent beyond the schema's individual property descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get'), resource ('layer'), and content scope ('transforms, timing, effects'), making the core purpose unambiguous. It does not explicitly contrast with sibling tools like ae_get_composition or ae_list_effects, but the resource and verb are specific enough to distinguish it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The only guidance is intra-tool parameter selection: 'Prefer layer_name; use layer_index if names collide.' No guidance is provided about when to use this tool versus alternatives, such as ae_get_composition, ae_list_effects, or mutation tools like ae_set_layer_properties.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of explaining behavior. 'List' implies a read-only operation and the parenthetical conveys the return content, but side-effect-free behavior, ordering, failure cases, and the implications of 'open project' are not explicitly disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with the action and scope front-loaded, followed by a tight parenthetical list of output fields. Every word contributes useful information with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter listing tool, naming the scope and the returned fields is sufficient for an agent to select and call it. The absence of an output schema is mitigated by the explicit field list, though minor details like ordering or error behavior are not mentioned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no parameter meaning for the description to add beyond the schema. The baseline of 4 applies because the no-parameter case needs no further elaboration.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' with a clear resource, 'compositions in the open project', and enumerates the returned fields: name, size, fps, duration, layer count. It is distinct from create/get/apply tools, though it does not explicitly contrast with similar list/get tools like ae_get_composition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives such as ae_get_composition or ae_get_project_info. The phrase 'in the open project' provides scope but no exclusions, conditions, or routing hints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full behavioral burden. 'List' implies read-only behavior, but the description never explicitly states that it has no side effects, what template scope is returned (project vs. installed library), or ordering/pagination behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence front-loads the action and object, has no filler, and earns its place. It is appropriately sized for a simple list operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter list, the definition is nearly adequate, but it omits how aspect_ratio affects the returned templates and gives no return-shape or behavioral details despite lacking an output schema. These gaps force an agent to guess about filtering behavior and result content.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single optional parameter, aspect_ratio, is left completely unexplained in the description, and schema description coverage is 0%, so the tool description does not compensate. The property name and enum values are somewhat self-explanatory, but it is unclear whether aspect_ratio filters results or simply hints at the desired output orientation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('List'), a concrete resource ('reusable motion-graphics templates'), and the planning context ('planning a YouTube video'). This clearly distinguishes it from sibling tools like ae_list_effects, which concern effects rather than templates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'when planning a YouTube video' gives clear, actionable use context for when this tool belongs in a workflow. It does not explicitly name alternatives or exclusions, but the context is specific enough for an agent to decide when listing templates is relevant.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It reveals that matching is by name substring but says nothing about return format, sorting, pagination, side effects, or behavior when the limit is reached. The read-only nature is only inferred from the word 'search'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no filler. The core purpose is front-loaded, and the usage preference is stated economically. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description should clarify what the tool returns, but it does not. It also omits parameter semantics for limit and include_layers, and does not explain default behavior or edge cases. For a simple search tool, this is still a notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, and the description does not compensate. It clarifies that the query targets names of project items and layers, which adds meaning beyond the schema's generic 'Case-insensitive substring', but limit and include_layers remain completely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Search') and a precise resource scope ('project items and layers by name substring'). It also draws a contrast with listing everything, which distinguishes it from broader retrieval tools like ae_list_compositions or ae_get_composition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: prefer it over listing everything in large projects. It does not name specific alternative tools or state explicit when-not-to-use cases, but the guidance is actionable enough for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
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 the clear behavior and a valid expression format. However, it omits behavioral traits like overwriting existing expressions, potential failure if the property doesn't support expressions, or any side effects. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences and an example with zero filler. The main action is front-loaded, and the clear behavior is stated in the second sentence. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description covers the core invocation and clearing behavior, but leaves out important context such as whether the expression overwrites existing expressions and what happens on failure. It is functional but not fully complete for an agent attempting first-time correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameter descriptions already document all six fields, including the null/empty clear semantics. The description adds only a usage example (wiggle(2, 30)) that clarifies expression syntax but does not significantly supplement the schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Set or clear') and identifies the exact resource ('expression on a layer property'), making the tool's function immediately clear. It also provides a concrete example (wiggle(2, 30)), which helps distinguish it from siblings like ae_set_keyframes or ae_set_effect_property.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives operational guidance (pass empty string/null to clear) but no contextual guidance on when to use this tool instead of alternatives such as ae_set_keyframes or ae_set_layer_properties. There is no mention of exclusions, prerequisites, or scenarios that would favor a sibling tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It communicates the mutation ('Create') and the target ('in a composition'), but it does not explain composition targeting semantics, insertion behavior, defaults, or failure modes. These are significant gaps for a mutating tool with 18 parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, stating the purpose first and then layering in type constraints and format conventions. Every sentence contributes useful information, and there is no filler or unnecessary repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 18 parameters, no output schema, and no annotations, this description is not complete enough for reliable invocation across all layer types. The text-layer path is reasonably covered, but solid, shape, camera, light, and adjustment layers lack the parameter guidance needed to construct valid calls. The description also omits return behavior and composition selection semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 22%, so the description must compensate. It adds useful semantics for color range (RGB 0–1), position vector length, and the text-layer parameter bundle. However, most parameters (scale, width, height, rotation, shape, opacity) remain unexplained beyond their names, and the required parameter sets for solid, shape, camera, light, and adjustment are not specified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a precise action and resource: 'Create a layer in a composition.' This clearly distinguishes it from sibling tools like ae_create_composition and ae_set_layer_properties. Listing the allowed type values adds specificity, even though the schema already constrains them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The opening sentence establishes clear context for when to use the tool. The type-specific guidance ('For text pass text/fontSize/fillColor') helps the agent shape arguments correctly. However, it does not mention alternatives or when-not-to-use conditions, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It adds useful context: the output is a PNG, it is returned as an image 'when possible', and it defaults to current CTI. But it leaves key traits undisclosed, such as whether the operation mutates anything, what happens when returning an image is not possible, and whether rendering is expensive or blocking.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. It front-loads the core operation first, then adds the usage trigger and default behavior. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is moderately complex and has no output schema, so return behavior matters. The description says a PNG image is returned 'when possible', but not what is returned when that is impossible, nor how composition selection works when both comp_name and comp_index are omitted. Since all parameters are optional, this is a material gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all four parameters are already documented in the schema; the baseline is 3. The description only restates the time behavior ('defaults to current CTI time'), which duplicates the schema's 'default current time', and adds no new parameter-level meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly names the action (render a still PNG), the resource (a composition), and the key parameter (time in seconds), which is more specific than the tool name alone. However, it does not distinguish itself from the sibling ae_capture_frames, so it does not fully meet the sibling-differentiation bar for a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent when to use the tool: after visual changes, so it can verify the result. The mention that it defaults to current CTI also signals it can be used for quick checks without arguments. It does not, however, contrast with ae_capture_frames or ae_render_composition, so exclusions are missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses default behavior (1920x1080, 30fps, 5 seconds) and the bgColor input format, which is useful since no annotations are provided. However, it does not describe side effects, connection requirements, return values, or error behavior for a mutating operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler, front-loaded with the operation before defaults. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple creation tool the essentials are covered, but with no output schema or annotations, the description should at least mention what callers get back or any side effect on the active project. PixelAspect semantics and lifecycle context are also omitted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 43%, but the description compensates for several properties by stating resolution, fps, duration, and a bgColor example. It does not clarify pixelAspect, which remains under-documented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and resource: 'Create a new composition' — a clear verb plus object. It differentiates the tool from sibling creation tools like ae_create_layer and ae_create_subtitle, and from inspection tools like ae_get_composition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 alternatives. It does not mention prerequisites, exclusions, or when to favor ae_create_layer or ae_import_footage instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description takes on the full burden of behavioral disclosure. The explicit 'DESTRUCTIVE' label and the confirm gate clearly warn the agent that this is a mutating, guarded operation. It does not describe irreversibility or downstream effects, but the safety-critical behavior is unusually well flagged for a one-line description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short phrases with no filler. The action is front-loaded, followed immediately by the safety warning and confirmation requirement. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the destructive nature and confirmation requirement well, but it does not clarify that at least one composition reference and one layer reference should be provided, despite the schema only marking confirm as required. It also says nothing about failure behavior or return values, leaving some operational ambiguity for a tool with no output schema and no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3 and the description does not need to add much. It merely restates the confirm=true requirement already present in the schema. No additional parameter-level nuance such as the preference ordering among name/index fields is given, though the schema itself already covers this.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the verb 'Delete' and the resource 'layer', leaving no ambiguity about what the tool does. It also distinguishes itself from non-destructive sibling tools like ae_duplicate_layer and ae_get_layer. The resource type explicitly separates it from ae_remove_effect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not state when to use this tool versus alternatives such as ae_duplicate_layer or ae_remove_effect. It only adds the call requirement 'requires confirm=true', which is an invocation gate, not a usage guideline. No exclusions or conditions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description clarifies that this is a summary-only read operation and explicitly lists the returned data, which is useful. However, with no annotations to rely on, it does not mention what happens if no project is open, how 'concise' vs 'detailed' affects the output, or whether any side effects occur.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with no filler. The main purpose and returned fields are front-loaded, and the usage guidance is a single clause in the second sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read tool, the description gives the essential purpose and output fields. Yet it omits the meaning of the response_format choices and any prerequisite or error behavior for when no project is open, and there is no output schema to fill those gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, response_format, has a clear enum and default in the schema, but the description never mentions it. Schema description coverage is 0%, and the description does not compensate by explaining how 'concise' or 'detailed' changes the summary.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Get the open AE project summary,' then lists the exact fields returned (name, path, bits, composition index). It also distinguishes itself from heavier introspection via 'Prefer this over dumping the full project tree,' making its purpose and scope unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Prefer this over dumping the full project tree' gives clear context for when this lightweight summary tool is a better choice than a heavier operation. It does not explicitly name an alternative sibling tool or state when not to use it, but the guidance is sufficient for basic routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the burden of behavior disclosure. It conveys a read-only listing operation and the output fields, but does not mention error behavior for missing layers, ambiguity resolution between names and indices, or return shape details such as ordering and empty results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the core action and resource, then packs the key return fields into a parenthetical. There is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool with fully documented parameters, the description is nearly sufficient. It names the expected output fields, though it omits edge-case behavior and explicit return type, which are minor given the low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: comp_name, comp_index, layer_name, and layer_index are all individually documented. The tool description adds no semantics beyond the schema, so the baseline score applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource — 'List effects on a layer' — and names the returned fields (name, matchName, index). This clearly differentiates it from sibling tools like ae_apply_effect or ae_remove_effect by action and intent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The verb 'List' implies this is the right tool when an agent needs to inspect existing effects, but there is no explicit guidance about when to prefer it over alternatives or when not to use it. Usage is conveyed indirectly rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry behavioral disclosure. 'List' reasonably implies a read-only enumeration rather than mutation, and the status set adds useful scope. However, it does not disclose return shape, ordering, limits, or whether results are scoped to a specific project.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence states the action, resource, and status scope with no filler. Every word contributes to the meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list tool, the description names the operation and the full status range it covers, which is enough to invoke the tool. It stops short of describing the contents of a review item or the response format, but the low complexity keeps this gap minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema already has 100% description coverage, so there is no parameter burden for the description to compensate for. The description's mention of status categories is sufficient given there is nothing to configure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and a specific resource ('AE MCP review items'), then narrows scope with the statuses 'pending, approved, and rejected'. This clearly distinguishes it from sibling mutation tools like ae_create_review and ae_decide_review.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states what the tool lists but provides no guidance on when to use it versus related review tools or how to interpret the statuses. There is no mention of alternatives, prerequisites, or context such as whether this reflects the current AE project.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden and does so reasonably: it explicitly states this is a read operation and explains the semantic difference between approval and autonomous modes. It does not mention edge cases like unset preferences or which defaults are returned, but for a zero-parameter getter the disclosed behavior is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler: the first sentence states exactly what is read, and the second provides meaningful context about mode semantics. It is front-loaded and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter getter with no output schema, the description covers the tool's purpose and the meaning of the two modes it returns. It is slightly incomplete in that it does not describe the shape of the returned preferences or behavior when nothing has been configured, but those gaps are minor for this complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is nothing for the description to explain beyond schema coverage. The baseline of 4 applies because no parameter documentation burden exists.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Read') and identifies the exact resources read: workflow mode, edit mode, and brand defaults. It clearly communicates the tool's scope but does not explicitly differentiate from the sibling set_workflow_preferences, relying on the verb instead.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by explaining what the workflow modes mean and noting that approval mode is the safe default, so an agent can infer when checking current preferences is relevant. However, it never explicitly states when to call this tool versus alternatives, nor does it name any when-not-to-use conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden, and it clearly discloses that the tool is non-mutating ('before any AE mutation') and returns a reviewable plan. It does not cover edge cases such as missing transcript input, but the key safety trait is visible.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one tight, front-loaded sentence that covers purpose, input, outputs, and safety in under 30 words. Every clause adds useful decision information, and there is no filler or repetition of schema metadata.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description conveys the core workflow and non-mutation guarantee well, but it leaves input selection and output shape underspecified. Since there is no output schema, the exact contents of the 'reviewable plan' are only partially described, and the optional transcript/transcript_path ambiguity remains unresolved.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the three parameters. It fails to clarify whether transcript and transcript_path are alternatives, what precedence applies, or how mode values (clean, retention, story) affect the resulting plan.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Create an explainable YouTube edit plan from a timed transcript.' It then lists the concrete outputs—natural cut points, a hook, chapters, and visuals—which clearly distinguishes it from sibling mutation and audit tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear workflow context: use this tool when you have a timed transcript and want a reviewable plan before making any AE changes. It does not explicitly name alternatives such as ae_transcript_to_cuts or ae_audit_editorial_plan, so it stops short of full when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It discloses key behaviors: verification runs first, a dedicated comp and layer are created, and a post-import capture frame is required. It does not discuss side effects like overwriting existing comps or the impact of skip_verify, but it provides substantial beyond-the-schema behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, front-loaded with the core purpose, then adds workflow behavior and the mandatory follow-up. Every sentence earns its place with no repetition or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The core workflow is captured well: import, verify, create comp/layer, then capture to confirm visibility. However, with seven parameters, no annotations, and no output schema, the description leaves several options unexplained. It is minimally adequate for a default call with just jobId, but incomplete for customizing or troubleshooting the import.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 29%, and the description does not compensate for the undocumented parameters. It never explains comp_name, layer_name, frameRate, threeD, first_frame, or skip_verify; the closest link is 'Runs verify first' hinting at skip_verify, but that is indirect. Only jobId is meaningfully contextualized via 'finished Blender exchange job.'
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action and resource: importing a finished Blender exchange job into After Effects as a transparent PNG sequence. It clearly differentiates this from generic import and Blender preparation/verification tools by specifying the output format and the fact that it creates a dedicated comp and layer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It states the input condition ('finished Blender exchange job'), notes that verification runs first, and mandates a follow-up ae_capture_frame call to prove visibility. It does not explicitly name alternatives or when-not-to-use cases, so it falls short of a perfect score, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It reveals key side effects: creating an exchange folder, returning paths and Blender Python, requiring a transparent PNG sequence, and the AE limitation regarding .blend meshes. It clearly communicates the sequential workflow and dependencies, making the behavior transparent enough for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loads the most important guidance ('MANDATORY first step'). Each sentence adds operational value: key constraint, exchange folder outputs, AE limitation, and the follow-up call. Minor redundancy exists but overall it is focused and structured clearly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a preparation tool with no output schema, the description supplies essential workflow context: the exchange folder, the returned artifacts, the AE/Blender limitation, and the required next step. It doesn't detail the exact return structure, but the description gives enough for an agent to understand the tool's role in the larger 3D pipeline.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 40% (job_name and object_name have descriptions; fps, frames, and resolution do not). The description does not add meaning for those undocumented parameters or explain how they affect the generated Blender Python. Since coverage is low, the description should compensate, but it doesn't address any of the individual parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('prepare') and resource ('Blender 3D job'), and clearly distinguishes this tool from siblings like ae_import_3d_from_blender and ae_verify_blender_job by framing it as the mandatory first step. It explains the tool's exact job: create an exchange folder and return paths plus Blender Python code.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use the tool: as a mandatory first step when the user asks for REAL 3D models in AE. It also gives a clear condition for the next step, calling ae_import_3d_from_blender after Blender finishes. However, it doesn't explicitly mention alternatives or when not to use it, though this is a relatively unique workflow step.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden and does disclose the visible side effect (brief 'Executing script…' dialog) and the rate limit ('30s cooldown'). It does not explain what internal state changes, prerequisites, or risks a reconnect involves, so some opacity remains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three compact sentences each carry distinct information: constraint, action plus visible effect, alternative, and cooldown. There is no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless tool with no output schema, the description supplies the key call-time facts: when it may be used, what the user sees, and the cooldown. It could mention success/failure behavior, but the core invocation context is covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero properties with 100% coverage, so there are no parameters to document and the baseline is 4. The description's command and dialog context is a bonus rather than a necessity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a concrete action ('Runs AfterFX -r once') and scopes it with 'USER-INITIATED ONLY', making the reconnect intent clear from the name plus verb. It doesn't explicitly define what reconnecting changes internally, but it is specific enough to distinguish this from sibling maintenance tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an explicit alternative ('Prefer restarting AE instead for a silent Startup load') and a hard usage constraint ('USER-INITIATED ONLY') plus a cooldown. An agent knows this is the manual, visible reconnect path and that silent startup should be handled by restarting AE instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full transparency burden. It discloses that the tool is always undo-grouped, that it returns a JSON-serializable value, and that unsafe mode is for arbitrary code. It also signals risk with 'escape hatch'. It does not detail error behavior or side-effect risks, but provides solid context for a low-level runner.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, front-loaded with the tool's nature ('Escape hatch'), and every sentence adds operational value. There is no filler or redundant restatement of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers return type, undo grouping, args passing, and tool hierarchy, which is strong for an escape-hatch tool. However, it leaves the restricted mode undefined and does not mention error or failure behavior, which is notable given there is no output schema and no annotations to fill those gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50%, so the description must compensate. It adds useful meaning to mode ('unsafe for arbitrary code') and mentions that args is passed into the function body. However, it does not explain the structure of args or the purpose/expected value of the description parameter, leaving gaps the schema also does not fill.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies this as an escape hatch for running arbitrary ExtendScript function bodies, which is a specific verb and resource. It also distinguishes itself from the many high-level AE tools by explicitly positioning itself as the low-level fallback.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The instruction 'Prefer high-level tools when possible' explicitly tells the agent when not to use this tool, and 'Use mode=unsafe for arbitrary code' gives meaningful mode guidance. However, it does not explain exactly when to use restricted mode versus unsafe mode, leaving some usage ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the ffmpeg dependency and that it returns segmentation results, but it doesn't state whether the operation is non-destructive, how results are structured, or what happens if ffmpeg is missing or fails. The behavior is mostly clear but not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences: function first, then usage context, then alternative. Every sentence earns its place, with no wordiness or repeated schema content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an analysis tool with no output schema, the description gives a clear sense of what it returns ('KEEP segments vs silence'), a prerequisite ('Requires ffmpeg on PATH'), and a routing option. It could specify the return format more precisely, but it's largely complete for selecting and invoking the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 5 parameters with clear descriptions. The description adds no parameter-specific meaning, which matches the baseline 3 for fully-covered schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Analyze'), a resource ('video'), a concrete method ('ffmpeg silencedetect'), and an explicit output ('KEEP segments vs silence to remove'). It also differentiates from speech-aware siblings by naming ae_transcribe_video and ae_transcript_to_cuts, so agents can clearly distinguish when to use this tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides direct when-to-use guidance: 'Use this BEFORE cutting — never guess random cut points.' It also names the exact alternative and condition: 'Prefer ae_transcribe_video + ae_transcript_to_cuts when you need to remove stutters/fillers (speech-aware).' This leaves no ambiguity about tool routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It explicitly states 'without mutating After Effects,' which is a key safety guarantee. It also discloses that the tool reports specific issue categories, though it does not describe the report's format or whether any other side effects exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence front-loads the action and resource, then lists report categories and the no-mutation guarantee. Every clause earns its place; there is no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter audit tool with no output schema, the description covers what it does, what it checks, and its safety profile. It does not detail the return structure, but 'Reports ... issues' is sufficient for an agent to understand the expected output. Minor gaps around output format keep it from a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: the only parameter, 'plan', is already described as the output of ae_create_editorial_plan. The description's reference to 'YouTube editorial plan' adds little beyond the schema. Baseline 3 is appropriate because the schema already documents the parameter well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Run'), a specific resource ('a pre-build quality audit on a YouTube editorial plan'), and enumerates the exact report categories: hook, pacing, coverage, chapter, and unsafe short-cut issues. This clearly distinguishes it from sibling audit tools like ae_audit_motion_coverage or ae_validate_motion_blueprint, which target different artifacts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'pre-build quality audit' gives a clear temporal context: run this after creating an editorial plan and before building the video. It does not explicitly name alternatives or state when not to use it, but the scope is specific enough that an agent can infer the intended stage without ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden. It clearly discloses the default white-text-with-black-stroke styling, the absolute behavior of not adding a background bar unless background_bar=true, and the requirement of explicit user intent. This prevents a common hallucinated default that a caption tool adds a black plate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earns its place: the purpose, the critical default behavior, and the routing guidance. No redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covering the most decision-critical behaviors (no bar by default, explicit-user-ask requirement, solid alternative) alongside schema-covered required parameters makes this adequate. It could add a bit more around barOpacity/fade semantics and what the operation returns, but those gaps are not blocking for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 62%, leaving y, fade, font, name, fontSize, and barOpacity undocumented. The description adds meaningful default-style context but does not explain those undocumented parameters or map defaults to specific fields beyond fillColor/background_bar implications, so it only partially compensates for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource — 'Add a subtitle/caption text layer' — and further differentiates it from the common alternative of creating a solid for captions. This makes it easy to distinguish from generic siblings like ae_create_layer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says 'Prefer this over solids for captions,' which gives the agent a clear rule for when this tool is the right choice relative to an alternative. It doesn't discuss exclusion cases or compare to ae_create_layer, but the caption-specific wording supplies enough context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the burden of behavioral disclosure. It reveals that the tool reads from a local directory (~/.ae-mcp/blender-exchange/) and 'List' implies a read-only operation, but it does not explicitly state side-effect-free behavior or what happens if the directory 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, no filler, and the most important scoping information (what is listed and where) is front-loaded. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With zero parameters and no output schema, the description is mostly sufficient: it states the source location and the resource type. It does not describe the return structure, but for a simple list tool this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no properties, so there are no parameters needing semantic explanation. The description adds no parameter detail because none exists, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and a specific resource ('Blender→AE exchange jobs'), and pins the scope to a concrete filesystem path. This clearly distinguishes it from sibling tools like ae_list_instances or ae_list_compositions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The location and resource are explicit, making it clear this tool is for listing Blender exchange jobs from a local directory. It does not list explicit exclusions or alternatives, but the domain-specific naming and path are sufficient contextual guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the burden of behavioral disclosure and does so well: it states that the tool writes a JSON file to a specific path, describes the shape of the output, and lists prerequisites. It does not mention potential long-running behavior, model download side effects, or the exact return value, but the core behavioral traits are transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three tightly crafted sentences cover purpose, output location, dependencies, and downstream usage. Every sentence adds necessary context without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a medium-complexity tool with no output schema, the description covers the essentials: what it produces, where it stores it, prerequisites, and the intended downstream workflow. It could be more explicit about the exact return value or timing behavior, but it provides enough to guide correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents path, model, and language. The description adds no additional parameter-level meaning beyond the schema, which matches the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific action and resource: 'Transcribe a video/audio file with timestamps'. It clearly differentiates the tool from siblings by naming the downstream consumer (ae_transcript_to_cuts) and describing the output format (segments + word-level).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides concrete usage context: required external dependencies (Python, faster-whisper/openai-whisper, ffmpeg), where output is saved, and how the result should be used downstream with ae_transcript_to_cuts. It lacks explicit when-not-to-use or exclusion guidance versus similar media-analysis siblings, so it stops short of full routing clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of explaining behavior, and it does so clearly: it removes filler words and stutters, builds KEEP segments using pad_before/pad_after, and returns cleaned text plus SRT. It also signals that the tool does not directly build the final edit, since segments are passed to ae_build_smart_edit. It does not explicitly discuss side effects or project mutations, but its processing-oriented nature makes the behavior reasonably transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three focused sentences front-load the core transformation, then give the downstream step and the subtitle output. There is no filler, and each sentence adds useful routing or behavioral information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even without an output schema, the description explains the main outputs: KEEP segments to pass to ae_build_smart_edit, cleaned text, and SRT. It also clarifies that subtitle creation should go through ae_create_subtitle. It does not detail the exact return structure, but for a high-level pipeline tool the behavioral and routing information is largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 78%, so most parameters are already explained in the schema. The description adds useful context for pad_before/pad_after ('so cuts have a little breathing room') and clarifies what filler/stutter removal means, but it does not systematically elaborate on every parameter. Baseline 3 is appropriate because the schema does most of the work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific transformation: turn a timed transcript into cleaned KEEP timeline segments with padding, while removing fillers and stutters. It names the input resource (timed transcript), the output artifact (segments, cleaned text, SRT), and points to a downstream sibling (ae_build_smart_edit), making its role in the pipeline unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear workflow context: it is used after transcription and produces segments to pass to ae_build_smart_edit, and it explicitly routes subtitle creation to ae_create_subtitle instead. It does not explicitly state when not to use it relative to other edit-building tools like ae_build_youtube_edit or ae_analyze_cuts, so it lacks full exclusionary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It clearly discloses the tool is a gate, what it checks, and the consequence of failure. It does not describe the return format or whether it mutates anything, but 'verify' plus explicit gate semantics makes the main behavior transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely tight: every sentence earns its place. It front-loads the gate purpose, states specific verification checks, and ends with a clear operational directive. There is no filler or redundant restatement of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and the gate context is well covered, but there is no output schema and no annotations, so the description should have explained how results are returned and what failure looks like operationally. The min_frames parameter is also unaddressed, leaving a real gap for an agent deciding how to invoke and interpret it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description needed to explain jobId and min_frames. It does not mention either parameter by name or meaning. 'Checks frame count' loosely relates to min_frames, but the threshold semantics and required jobId are left entirely to the agent to infer from the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: it verifies a Blender job and explicitly names it a 'VERIFY GATE' for AE import. It lists concrete checks (frame count, frames differing, mesh exports), which clearly distinguishes it from the sibling ae_import_3d_from_blender tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is explicitly prescribed: 'MUST pass before ae_import_3d_from_blender' and 'Do not claim 3D is done if this fails.' This gives the agent unambiguous when-to-use and when-not-to-claim-success guidance, and implicitly routes it to the import tool only after this gate passes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden and does disclose the key side effects: importing footage when a path is provided and creating a sequential edit comp. It also reveals the selection behavior (silence/dead air, not random) and a negative behavior (no subtitle bars). It does not state overwrite behavior for an existing comp name, but the core mutation and output type are explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences with no filler. The primary action is front-loaded, followed by two behavior notes that each earn their place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description supplies the essential prerequisites (segments from ae_analyze_cuts), the optional import behavior, the cut criterion, and a notable non-goal. It only leaves minor ambiguity about how to provide footage when it is not already in the project and about the exact return or comp naming behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds practical meaning over the schema: 'optional if already in project' clarifies the path/footage_name choice, and 'KEEP segments from ae_analyze_cuts' reinforces what segments must contain. It does not elaborate on comp_name or frameRate, but these have defaults and the schema already covers 60% of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action (build a sequential edit comp), the input source (KEEP segments from ae_analyze_cuts), and the processing behavior (cuts on silence/dead air). It also distinguishes itself by stating it does not add subtitle bars, separating it from related editing and subtitle tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It tells the agent that importing is optional when footage is already in the project, implying when path vs footage_name should be used, and it positions the tool as the follow-up to ae_analyze_cuts. It does not explicitly name alternatives such as ae_build_youtube_edit, but the silence/dead-air criterion and 'no subtitle bars' note provide clear context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavior disclosure. It transparently describes the operation as listing only live, heartbeat-reporting instances, implying a non-mutating read of bridge state. It doesn't detail output shape or failure behavior, but for a simple list operation no significant hidden side effects are implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no filler. Every word adds meaning, and the core action and scoping constraint are immediately visible.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless list tool with no output schema, this description is complete: it names the resource, the exact subset ('live ... reporting heartbeats'), and the transport ('file bridge'). An agent has enough information to invoke it correctly and interpret the intent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description correctly avoids inventing parameters and needs to explain none.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List'), a clear resource ('live After Effects instances'), and a precise selection criterion ('reporting heartbeats to the file bridge'). This makes it easy to distinguish from sibling tools such as ae_list_compositions or ae_list_effects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use the tool: when you need to see which After Effects instances are live and currently heartbeating to the bridge. It doesn't explicitly name alternatives or exclusions, but the context is clear for a zero-parameter discovery tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It clearly states the tool is a read-only status check with no script execution side effect, which is important context. However, it does not state what the actual status output looks like (e.g., connected/disconnected status shape), so a small behavioral gap remains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no wasted words. The most important information ('Check... status only') is front-loaded, followed by a clear exclusion and a practical fallback instruction.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter health-check tool, the description is nearly complete: it defines the action, the safety boundary, and the next step if disconnected. The only missing piece is a description of the return value/status format, and no output schema exists to fill that gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there are no parameter semantics to document. The baseline for 0-param tools is 4, and the description appropriately adds no irrelevant parameter detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Check After Effects bridge status only.' It differentiates itself from siblings by explicitly saying it never runs scripts, which is essential given siblings like ae_run_jsx. This leaves no ambiguity about the tool's core purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states what the tool is for ('Check... status only') and what it is not for ('Never runs scripts in AE'). It also provides actionable guidance for the disconnected case: 'restart AE once or call ae_reconnect once.' This is explicit when/when-not guidance with a named alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GitHub Badge
Glama performs regular codebase and documentation scans to:
- Confirm that the MCP server is working as expected.
- Confirm that there are no obvious security issues.
- Evaluate tool definition quality.
Our badge communicates server capabilities, safety, and installation instructions.
Card Badge
Copy to your README.md:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/HeroicSwan/after-effects-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server