Server Quality Checklist

Tool Scores

• ae_layerC
  2.8/5.0
  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 that list is lightweight and get with deep:true returns full detail, which implies performance characteristics. However, it does not disclose side effects of mutating actions like create, delete, or set, nor does it indicate whether operations require specific permissions, are reversible, or have any error states. For a tool with many destructive actions, this is a significant gap.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise at two sentences, which is efficient for a tool with 64 parameters. It front-loads the main purpose and the key action hints. However, given the tool's complexity, the brevity borders on under-specification rather than effective conciseness; it does not use structure like bullet points or sections to organize the many capabilities.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema, no annotations, and 64 parameters, the description is far from complete. It does not explain how to specify layers (by name, index, id, 'selected', 'all') even though the schema lists this, nor does it describe common behaviors like parent-child relationships, threeD, or time-based parameters. The tool is a comprehensive layer management tool, and a two-line description is inadequate for guiding an agent on correct invocation.

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

  Parameters2/5

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

  Schema description coverage is 58%, so about 42% of parameters lack schema descriptions. The tool description adds minimal value beyond the schema: it mentions the action list and the deep flag behavior but does not explain key parameters like layer, comp, or the various create-specific properties. Since coverage is moderate, the description should compensate for undocumented parameters, but it fails to do so, leaving many parameters ambiguous.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool creates, lists, reads, and modifies layers, with a specific list of layer types. It communicates the core purpose with a verb and resource. However, it does not differentiate from sibling tools like ae_shape, ae_mask, or ae_animate, which also deal with layer-related concepts, so the purpose is clear but not distinguished from alternatives.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives a concrete usage hint: 'action=list est leger (a privilegier pour explorer)' recommending list for lightweight exploration, and 'action=get deep:true renvoie tout le detail' for full details. This provides some guidance on when to use specific actions, but it does not explain when to use this tool instead of sibling tools like ae_shape or ae_property, nor does it mention exclusions or prerequisites.

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

• ae_propertyC
  2.9/5.0
  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 mentions read and write capabilities and expression handling but does not describe side effects, error behavior, requirements (e.g., layer existence, permissions), or what happens when setting properties (overwrite, animation handling). The lack of such details for a mutation-capable tool is a significant omission.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences, front-loading the core read/write functionality and then briefly covering expressions and tree exploration. It is efficient, with no fluff or redundancy, and every clause earns its place given the tool's breadth.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has 15 parameters, 5 actions, and no output schema. The description provides an overview but does not explain what each action returns, how parameters interact, or any constraints (e.g., when 'time' applies, how 'properties' batch works). An agent would need to consult the schema and likely the help tool to use it correctly, making the description insufficient for a tool of this complexity.

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

  Parameters3/5

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

  The schema already has 100% coverage with descriptions for all 15 parameters, so the baseline is 3. The description adds some conceptual context by mentioning expression modes (raw code vs parameterized recipe) and property tree exploration, which helps map the 'expression' and 'recipe' parameters and the 'tree' action. However, it does not materially deepen understanding beyond the schema's own explanations.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool reads and writes any layer property via path, covering effects, vector contents, and masks, and also handles expressions and tree exploration. The verb+resource is specific ('Lire et ecrire n'importe quelle propriete d'un calque'), distinguishing it as a general-purpose property tool, though it does not explicitly name sibling tools to contrast with.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description does not provide guidance on when to use this tool versus siblings like ae_effect, ae_keyframes, or ae_text. It does not state preferred scenarios, exclusions, or conditions that would steer an agent toward an alternative. With many sibling tools that likely overlap, this gap forces the agent to infer usage from the tool's generic scope.

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

• ae_rigC
  2.9/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the disclosure burden and does convey the main artifacts produced: control nulls with UI widgets, expression-based links, layer alignment/distribution, and parenting. It stops short of revealing side effects — whether existing layer transforms are overwritten, whether new layers are inserted into the comp, or how reversible the operations are. The schema adds a little (keepTransform default true), but the overall behavioral contract remains thin.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact — two sentences covering the tool's umbrella purpose plus one action detail — and is front-loaded with 'Construit des rigs'. However, the metaphor 'comme un monteur' adds little (a monteur is a film editor, not a rigging artist) and the placement of the action=essential sentence is arbitrary, since exportMogrt and bounds actions are left out of the prose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with 23 parameters, 7 actions, no annotations, and no output schema, this description is incomplete: it narrates only control/link/align/parent/essential and leaves bounds and exportMogrt to be inferred solely from parameter descriptions. It also says nothing about prerequisites (open comp, selected layers) or what the tool returns after building a rig. An agent would need to open the schema and still guess at behavior for two of the seven actions.

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

  Parameters3/5

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

  Schema coverage is 70%, so the baseline is 3 and the schema already documents most parameters with per-action notes (e.g., 'link : propriete a piloter'). The description adds action-level semantics that help interpret parameter groups, such as 'liens par expression' for link's path/target/targetPath/suffix. But uncovered parameters — parent, spacing, overwrite, distributeH/distributeV — are not explained by the description either, so it does not fill the remaining 30% gap.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb and resource ('Construit des rigs') and enumerates concrete operations: control nulls with sliders/colors/checkboxes, expression links (pickwhip), alignment/distribution, and parenting. It also clarifies the 'essential' action in a second sentence. However, it never names or differentiates sibling tools, so the boundaries against ae_property or ae_animate are left implicit.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is given on when to prefer this tool over siblings — nothing contrasts it with ae_animate (animation), ae_property (expressions), or ae_layer (hierarchy). The action enum in the schema hints at internal sub-uses, but the description itself provides no conditions, prerequisites, or exclusions.

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

• ae_maskB
  3.2/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full behavioral disclosure burden. It lists capabilities but does not disclose side effects such as whether create replaces existing masks, how set behaves on properties, coordinate system details, idempotency, or whether changes are destructive. This is a significant gap for a mutation tool with 20 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/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact: two sentences with no filler. The core purpose is front-loaded, and the animation routing hint is placed after the primary capabilities. Every sentence contributes useful context.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's complexity — 20 parameters, two actions, nested object inputs, no output schema, and no annotations — the description is too short to be complete. It provides a useful overview and one workflow hint, but it omits actionable details about result behavior, property setting semantics, shape coordinate systems, and error conditions.

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

  Parameters2/5

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

  Schema description coverage is only 35%, so the description must compensate. It maps general concepts like shape, mode, feather, expansion, and opacity, but many critical parameters such as vertices, inTangents, outTangents, center, inverted, locked, and closed remain unexplained. The description does not provide enough parameter-level meaning for an agent to confidently build complex mask operations.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific action, 'Creer et regler des masques', and details the resource domain: rectangle, ellipse, or free Bezier path, with mode, feather, expansion, and opacity. It clearly conveys what the tool does, though it does not explicitly differentiate it from sibling tools like ae_shape or ae_property.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the tool is used for creating and adjusting masks, and it gives contextual routing by stating that mask paths are then animated via ae_keyframes on 'masks/Mask 1/Mask Path'. It does not provide exclusions or explicitly compare against alternatives, but the practical workflow guidance is clear.

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

• ae_helpB
  3.3/5.0
  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 disclosing behavior. It only lists content categories and does not state what the tool actually returns (e.g., a formatted text document, a list, a single topic page), whether it has side effects, or any restrictions. For a help tool, it likely has no side effects, but that is not disclosed, leaving a significant 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/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence that front-loads the key content types and has no redundant words. It is concise and efficiently communicates the purpose without waste.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description lists content areas and the schema explains parameters, but it does not clarify the exact output format or how 'search' interacts with 'topic'. Since there is no output schema, the description should provide more about the return value. It is adequate for a simple help tool but has gaps around the actual behavior.

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

  Parameters3/5

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

  Schema description coverage is 100%: both 'topic' and 'search' are described in the schema, and the enum values align with the content categories listed in the description. The description adds a little context by enumerating those categories but does not add syntax or format details beyond the schema. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific resource: a reference for kernel commands, property paths, matchNames, easing curves, expressions, shape types, and text animators. The title 'Documentation du serveur AE' reinforces that it provides documentation. This distinguishes it from sibling tools that perform actions (ae_run, ae_shape, etc.), though it could be more explicit that it returns documentation content.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the tool is for retrieving reference documentation, which is distinct from the task-oriented siblings. However, there is no explicit guidance on when to use it versus alternatives, nor any mention of when not to use it. The context is clear but not explicitly stated.

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

• ae_compB
  3.4/5.0
  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 provides one explicit behavioral warning about the volume of deep:true, which is useful. It does not disclose other side effects (e.g., delete being destructive, permission requirements, or that most actions mutate state). The single warning earns a 3, but richer disclosure would be needed for a higher score.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence plus a brief tip, efficiently listing operations and front-loading the primary purpose. It avoids redundancy and is appropriately sized for the scope of the tool. The structure is clean, though it could arguably be more explicit about parameter usage.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the complexity (30 parameters, 9 action enums, no output schema), the description is not fully complete. It does not describe the output format, parameter interactions, or default behaviors for actions beyond the schema. The deep:true warning adds useful context, but an agent might need to consult the schema heavily for correct invocation. It is adequate but with gaps.

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

  Parameters3/5

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

  Schema coverage is 73%, so most parameters have descriptions in the schema. The description adds context for deep (detailed layer content) and warns about volume, but it does not explain many parameters like 'only', 'depth', 'clear', or the precedence between 'duration' and 'durationFrames'. The description adds marginal value beyond the schema, and the coverage is not high enough to rely solely on it, so a 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the resource (compositions) and lists a range of operations (create, read, modify, duplicate, precompose, open, set markers, move playhead). It distinguishes itself from sibling tools by focusing on compositions, though it does not explicitly contrast with ae_layer or ae_property. The multi-action scope is clear but not a single specific verb, so it's a high 4.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives a specific usage tip for reading detailed content via deep:true with a volume warning, which helps avoid excessive output. However, it does not explicitly state when to use this tool versus alternatives like ae_layer for layer-level operations, or provide any exclusionary guidance. The guidance is implied but not comprehensive.

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

• ae_projectB
  3.4/5.0
  Behavior3/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 disclosing behavior. It honestly lists the operation range, including suppression (deleteItems) and enregistrement (save), which signals destructiveness and persistent side effects. However, it does not warn that deletions are irreversible or describe side effects of save/set operations on the project state. Adequate but shallow for a tool that can mutate and destroy.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  One compact sentence that front-loads the purpose and enumerates the operation families without padding. For a tool spanning seven actions and 13 parameters, the brevity is appropriate and every listed item maps to a real operation in the schema.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the complexity (7 action variants, 13 params, no output schema, no annotations), the description is a serviceable high-level overview but lacks guidance on selecting among the actions (e.g., when to use import vs set vs moveItems) and gives no expectation of return values. An agent would need to consult the schema for each parameter but would still be guessing at action-selection criteria for a given user goal.

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

  Parameters3/5

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

  Schema coverage is 100%, so the schema already documents all 13 parameters and their action-conditional meanings. The description adds marginal contextual value by noting that PSD/AI files import as comps and that 'reglages projet' corresponds to the set action — loose ties to the importAs and action enums. This meets the baseline 3 but does not exceed it, since the schema carries the substantive burden.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific resource (project) and enumerates its operation families: inventory (get), import, folders, save, delete, settings. This gives a clear sense of scope and differentiates it from the sibling tools that target specific object types (ae_layer, ae_comp, ae_shape). It is slightly broad because it bundles seven actions into one tool, but the listed operations map directly to the action enum.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The scope is implied by the enumerated operations — project-level management — but the description never names sibling tools or explains when to choose ae_project over ae_layer, ae_comp, or others. There is no explicit when-to-use/when-not-to-use guidance or exclusion criteria, so an agent must infer boundaries from the operation list alone.

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

• ae_textB
  3.4/5.0
  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 disclosing behavioral traits. It only lists actions without mentioning side effects such as overwriting existing keyframes (the 'clear' parameter defaults to true), reversibility, permissions, or impact on existing animators. This is a significant gap for a tool that can mutate properties.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences, front-loaded with the primary purpose and a brief note about the fonts action. Every clause adds value with no redundancy, and it is appropriately sized for the tool's complexity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given 11 parameters and three distinct actions, the description lacks high-level guidance on when to use each action, how they relate, and what workflow patterns are expected. It only hints at the fonts action. The schema is exhaustive but provides no narrative, so the agent must piece together the purpose and usage from sparse cues.

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

  Parameters3/5

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

  Schema description coverage is 100%, so all parameters are documented in the schema. The description adds one extra detail: 'action=fonts liste les polices installées', which clarifies the fonts action beyond the generic schema type. However, it doesn't explain the differences between 'set', 'animator', and 'fonts' actions or how to combine them, leaving the agent to infer from the schema alone.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states specific verbs and resources: modifier le contenu et la mise en forme d'un calque texte, animer le texte source, et créer des animateurs de texte. It also distinguishes itself from generic animation tools by focusing on text layers and titles, making it clear what this tool is for.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for titles and animated typography ('c'est l'outil des titrages et des typographies animées'), but it doesn't explicitly state when to use this tool over alternatives like ae_animate, nor does it provide exclusions or conditions. It gives context but no clear routing.

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

• ae_animateA
  3.5/5.0
  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 adds a genuinely useful trait: 'Les valeurs sont relatives a l'etat actuel du calque : un slideIn ne detruit pas la position existante' (relative values, non-destructive). But for a mutation-heavy tool it does not disclose keyframe overwrite behavior, reversibility, or what happens to existing animation data beyond that one example.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three front-loaded clauses with zero filler: main purpose first, then the key behavioral caveat, then a discovery hint. Every sentence earns its place and the most important information appears immediately.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a 29-parameter tool with no output schema and no annotations, this is a thin description. It covers the core concept, the relative-value behavior, and the action=list escape hatch, but does not describe return behavior, error handling, or how parameters map across the preset, sequence, and apply actions. The action=list hint mitigates but does not close the gap.

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

  Parameters3/5

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

  Schema coverage is only ~55%, so the description should compensate for the ~12 undocumented parameters (to, from, amount, angle, distance, reverse, frequency, overshoot, etc.). It adds the core relative-values concept and routes discovery to action=list, but does not clarify what the undocumented parameters mean for specific presets, leaving an agent to guess their roles.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb ('applique' applies) and resource (ready-made animations: apparitions, sorties, effets de titre) plus a second distinct function (etale des calques dans le temps, staggering layers). It is specific enough to separate from manual-keyframe tools like ae_keyframes, though it does not name that sibling explicitly.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  There is clear implicit context of when to use it (one-command presets and layer sequencing), and 'action=list detaille les presets' offers a discovery path. However, it gives no explicit alternatives, no when-not-to-use conditions, and no guidance on choosing this over ae_keyframes or ae_effect for the same scenario.

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

• ae_runA
  3.6/5.0
  Behavior3/5

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

  The description discloses that batch operations are atomic with a single undo, which is valuable behavioral context. It also explains the template syntax for referencing previous step results, which is important for safe usage. However, it does not mention any risks, side effects, or state mutations beyond undo grouping; with no annotations provided, it could be more transparent about the power and potential destructiveness of kernel commands.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is reasonably concise and front-loaded with the core purpose and positioning. The batch usage example is detailed but necessary for correct invocation. It could be slightly more structured, but every sentence contributes to understanding the tool's role and usage.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given there is no output schema and no annotations, the description does a good job explaining the tool's role, batch atomicity, and reference syntax. It points to ae_help for command specifics, which is a practical completeness strategy. However, it doesn't describe return values or error behavior, and the interaction between single command and batch is left implicit.

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

  Parameters3/5

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

  The input schema already provides 100% coverage with descriptions for every parameter. The description adds meaningful context for the batch parameter by explaining the {{index.chemin}} and {{prev.xxx}} syntax, which goes beyond the schema. However, it doesn't clarify how args, command, and batch interact (e.g., whether command/args is mutually exclusive with batch), which would add further value.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states it provides direct access to all kernel commands, either single or batch, and positions it as the most powerful tool covering everything other tools do plus edge cases. It distinguishes itself from specialized siblings by being the generic/raw access tool. It falls short of a 5 because it doesn't explicitly name a sibling it should be preferred over, though the contrast is implied.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly says this tool is the most powerful and covers everything other tools do plus unanticipated cases, which tells the agent when to use it: for raw or batch operations not covered by specialized tools. It also directs to ae_help for the command list and arguments. It lacks explicit when-not-to-use guidance and alternatives, but the sibling context makes the division of labor fairly clear.

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

• ae_uiA
  4/5.0
  Behavior3/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 disclosing behavior. It explains the actions (driving the UI, executing menus) but does not mention side effects (e.g., UI changes, potential non-reversibility), prerequisites (After Effects must be open with a project), error behavior, or whether the operation is blocking. The description is honest about scope but lacks depth on consequences.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence that starts with the main verb and resource, then lists key capabilities and examples. It is moderately long but every clause carries information. The examples are useful but slightly verbose; still, it remains tight relative to the tool's complexity (8 params, 4 actions).

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with 8 parameters, 4 actions, and no output schema, the description does not explain return values, success/failure indicators, or whether the operation blocks until completion. It provides examples that help an agent understand typical use, but leaves ambiguity around behavior after invocation (e.g., does it return anything? does it wait for UI to settle?). The description covers the 'what' but not the 'what happens'.

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

  Parameters4/5

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

  Schema coverage is 100% (all 8 params have descriptions), so baseline is 3. The description adds value by specifying that menu commands can be given by name in English or French, which is extra semantics beyond the schema's minimal 'nom de la commande' for the command parameter. It also maps the action enum to its capabilities (menus, playhead, selection, comp opening), reinforcing the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool controls After Effects like a user (executing menu commands, moving playhead, selecting layers, opening compositions). It distinguishes itself from siblings by specifying it's for operations without scripted equivalents, giving concrete examples ('Create Shapes from Text', 'Convert Audio to Keyframes'), which differentiates it from ae_run or ae_comp.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly says the tool is useful for operations 'without scripted equivalent', implying when to use it. It lists example menu commands that have no direct script, giving clear context. However, it does not name specific alternative tools (like ae_run for scripts) or state when NOT to use it, so it falls short of full explicitness.

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

• ae_evalA
  4.1/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden, and it discloses important behavior: execution within an undo group, access to 'app' and AEMCP utilities, and that the last evaluated expression is returned as JSON-serializable data. It does not explicitly mention potential side effects or read-only guarantees, but the 'arbitrary code' framing implies both possibilities, and the undo group hint adds context.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a few sentences, front-loads the core purpose and usage constraint, and provides necessary context (access to app/AEMCP, return format) without clutter. It could trim minor redundancy but is appropriately concise for a powerful tool.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the high complexity of arbitrary code execution, the description covers key aspects: the execution context, the undo group, available APIs, and return value contract. It lacks explicit error-handling notes, but that is often implied for eval tools. No output schema exists, so the return-type note is valuable.

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

  Parameters3/5

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

  Schema coverage is only 33%, so the description must compensate. It explains the 'code' parameter with an example and indirectly hints at 'undoGroup' by mentioning the undo group, but 'timeoutMs' is left unexplained. The description adds some meaning to the code parameter but does not fully cover the undocumented parameters.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a clear verb ('exécuter du code ExtendScript arbitraire') and resource (After Effects) and explicitly frames it as a last-resort tool distinct from siblings. It positions itself as the fallback when no other tool covers the need, which differentiates it clearly.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly says 'A utiliser uniquement quand aucun autre outil ne couvre le besoin', giving a clear condition for when to use it. It doesn't name specific alternative tools, but the instruction to prefer other tools is unambiguous and sufficient guidance.

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

• ae_keyframesA
  4.1/5.0
  Behavior4/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 explicitly discloses that After Effects influences and speeds are computed automatically, 'comme un reglage manuel de l'editeur de graphe' (like a manual graph editor adjustment), which is a meaningful behavioral trait. It also explains the semantics of the 'ease' field. However, it does not mention any destructive implications of 'delete' or 'clear', which would have warranted a higher score.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded: it states the core purpose in the first sentence, then elaborates on the key behavioral nuance. Every sentence earns its place, and there is no redundant filler. The structure is effective for quick parsing.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's complexity (12 parameters, 4 distinct actions), the description is somewhat thin on action-specific guidance. It does not explain what 'get' returns, what 'shift' requires (though the schema covers this), or potential error conditions. The coverage is adequate for a high-level understanding but incomplete for an agent that needs to handle all actions confidently without supplementary schema inspection.

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

  Parameters4/5

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

  Although the schema covers all 12 parameters at 100% coverage, the description adds valuable context beyond the schema. It explains the 'ease' field's meaning and the available curve names (expo.out, back.out, etc.), and it clarifies path shortcuts like 'transform/position' and Adobe matchNames. This goes beyond simple schema repetition and helps agents understand the conceptual model.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a clear, specific verb and resource: 'Poser, lire, supprimer et decaler des keyframes' (place, read, delete, and shift keyframes), and adds a distinctive qualifier 'avec de vraies courbes de vitesse' (with real speed curves). This immediately distinguishes the tool from siblings like ae_animate or ae_property, which handle broader animation or property tasks.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for keyframe manipulation but never explicitly states when to prefer this tool over alternatives, nor does it mention exclusions (e.g., 'use ae_animate for purely procedural animation'). The 'action' enum in the schema gives some context, but the description itself lacks direct guidance on tool selection.

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

• ae_shapeA
  4.1/5.0
  Behavior3/5

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

  With no annotations, the description carries the behavioral burden. It adds useful behavior: it creates native shape layers and converts SVG into editable paths, not imported images. However, it does not disclose side effects, destructive behavior, or output/return behavior, which are significant given the mutation-oriented actions.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three sentences, each contributing distinct value: what the tool does, when the svg action is preferable, and where to find syntax details. No filler or redundant restatement of the schema.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given 29 parameters, three distinct actions, and no output schema or annotations, the description gives a useful overview but is not complete enough on its own. The pointer to ae_help helps, but the agent still needs to inspect the schema and related help to understand action-specific requirements and expected outcomes.

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

  Parameters4/5

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

  Schema coverage is 69%, so the schema already documents most parameters. The description adds meaning by mapping actions to high-level behaviors and by pointing to ae_help topic='shapes' for the syntax of vector items, which is especially valuable for the under-documented 'contents' parameter.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description names three concrete operations with specific resources: building native shape layers, modifying a Bezier path, and converting SVG into editable AE shapes. This clearly distinguishes the tool from siblings like ae_mask or ae_text and clarifies the role of the 'action' parameter.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It gives clear context for when to use action=svg: as the right entry point for recreating a vector design, because it produces real paths rather than an imported image. It does not explicitly state when not to use the tool or name alternatives, so it falls short of a 5.

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

• ae_effectA
  4.2/5.0
  Behavior3/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. It discloses a key behavioral nuance: matchName is more reliable when the UI language differs, and parameters can be named in two ways. However, it does not mention whether operations mutate the project, require specific layer selection, or have side effects. For a manipulation tool, this is a notable gap, though 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences, front-loaded with the primary operations. The key hint about matchName and naming is included without redundancy. Every sentence earns its place, and no filler exists.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given 13 parameters including nested objects, the description is concise but sufficient for understanding the tool's role. It covers the critical naming nuance and the list operation. The schema handles parameter-level details, so the description doesn't need to restate them. Minor missing context about return values or side effects, but for an effect manipulation tool, this is adequate.

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

  Parameters4/5

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

  The schema covers 100% of parameters with descriptions, so baseline is 3. The tool description adds value beyond the schema by clarifying that parameters are given by display name or matchName, and by explaining the purpose of 'list' for finding matchName. This helps an agent understand naming semantics that the schema alone does not convey.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb set applied to a clear resource: 'Chercher, appliquer, regler et retirer des effets' (search, apply, adjust, remove effects). It distinguishes this tool from siblings like ae_property or ae_layer by explicitly targeting effects, and the action enum (list/apply/set/remove) adds precision. This is 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/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives concrete usage guidance: it explains that 'action=list' is used to retrieve the exact matchName of an effect, which is essential when the AE interface is not in English, and that parameters can be given by display name or matchName. It doesn't explicitly state when not to use it or name alternative tools, but the guidance is actionable and context-specific.

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

• ae_statusA
  4.2/5.0
  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 behavioral disclosure. It states it 'verifies' the connection and lists return values, which implies a read-only operation, but it does not explicitly confirm it has no side effects or describe failure behavior (e.g., if After Effects is not running). It adds some value by listing returned data but lacks explicit safety guarantees.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, well-structured sentence (with a second short directive) that front-loads the core purpose and uses no filler. Every phrase contributes value: it identifies the action, the expected return data, and the recommended usage context. It is efficient and free of redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the low complexity (no parameters, no output schema), the description is largely complete. It specifies the returned data items (version, project, active composition, list of compositions) and gives usage guidance. It does not detail the exact output format (e.g., JSON structure), but since there is no output schema, this is a minor gap. Overall, it provides sufficient context for an agent to call the tool correctly.

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

  Parameters4/5

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

  This tool has zero parameters, and the schema coverage is 100% (empty properties object). Per the rubric, a 0-parameter tool gets a baseline of 4 because there is no parameter information to document. The description correctly focuses on behavior and return values rather than parameters, adding no unnecessary parameter semantics.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool checks the connection to After Effects and returns specific data (version, open project, active composition, list of compositions). It uses a specific verb ('Verifie la connexion') and identifies the resource and exact outputs, making it distinct from sibling tools like ae_run or ae_help which perform actions or provide help.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly says 'A appeler en premier en cas de doute sur la connexion' (call it first in case of doubt about the connection), providing clear when-to-use guidance. However, it does not mention when not to use it or describe alternatives (like ae_help), so it falls short of the full 5 criterion that requires when-not and alternatives.

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

• ae_renderA
  4.7/5.0
  Behavior4/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 that images are costly in context and persist for the conversation, advises on verification frequency, and explains behavioral details of includeImage (auto-false beyond 3 timestamps returns paths) and maxDimension cost scaling. This is strong, though it doesn't cover every edge case (e.g., queue/start failure modes), so a 4 is appropriate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two compact sentences that front-load the core purpose and seamlessly integrate usage guidance with parameter nuances. Every clause earns its place; no fluff or repetition. The structure is efficient and highly readable.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a 15-parameter tool with two operation modes, the description covers the key operational contexts (cost, verification strategy, maxDimension handling) and mentions queue/start. It doesn't fully describe the queue/start workflow or return details, and there's no output schema, but the schema handles most parameter specifics. Given the complexity, it's fairly complete, though a note on return behavior for queue/start would round it out.

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

  Parameters5/5

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

  Schema coverage is high (87%), but the description adds significant value beyond it. For action, it explains the two operation families; for maxDimension, it explains the token cost and recommends defaults; for includeImage, it clarifies the automatic behavior beyond 3 timestamps. These insights are not present in the schema, making the description essential for correct usage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's dual purpose: action=snapshot renders and returns an image of the composition at a given moment (the visual verification loop), while action=queue/start control After Effects' render queue. It uses specific verbs and a clear resource (composition, render queue) and distinguishes between the two action modes, making it easy for an agent to know what to expect.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides explicit usage guidance: verify after a block of operations rather than each keyframe, keep maxDimension low (default 700) unless inspecting details, and explains the cost/context implications. It also clarifies that queue/start handle the render queue. Though it doesn't name alternative tools, it gives actionable when/how to use guidance that directly informs tool selection.

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