mcp-after-effects

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

The description explains the tool's behavior beyond the read-only annotation: it lists categories vs. detailed params, and highlights that only executable operations are listed, setting accurate expectations. The readOnlyHint=true annotation aligns with the description's non-mutating purpose; no contradiction exists, and the description adds useful context about the two output modes.

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

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

The description is two sentences long and front-loaded with the primary purpose. Both sentences earn their place: the first states what the tool does, and the second details the two invocation modes and the guarantee about listed operations. No wasted words.

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

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

For a simple catalog tool with one optional parameter, read-only annotation, and no output schema, the description provides sufficient context: it explains the return content (categories or params) and the filtering guarantee. Minor omission is that it doesn't explicitly mention operation counts, but the schema's parameter description covers that, making it complete enough.

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

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

The input schema already provides a 100%-coverage description for the single parameter, including behavior when omitted. The tool description reinforces and expands on this by clarifying the exact difference between no-args and with-category outputs, adding value beyond the schema alone.

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

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

The description clearly identifies the tool as a discovery mechanism for atomic operations available to ae_do, with a specific verb ('Discover') and a defined resource (available atomic operations). It distinguishes itself from sibling tools like ae_do (which executes operations) and other project/layer tools that serve different purposes.

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

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

The description explicitly explains usage without args (list all categories) and with a category (detailed params per operation), giving clear context for both modes. It also states that only operations the server will execute are listed, which is a key guideline for filtering. It does not name specific alternatives, but the distinction from ae_do is implicit in the wording.

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

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

Annotations declare readOnlyHint, so safety is covered. The description adds meaningful behavioral context by listing the exact comp properties returned and noting that an array fetches several comps in one call, which tells the agent what to expect beyond annotations.

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

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

Two tightly packed sentences with zero filler. The key capabilities (returned fields, batching) are front-loaded and easy to scan.

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

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

For a read-only info tool with no output schema, the description adequately enumerates the returned data and batching behavior. It could mention error cases or use of the instance parameter, but the schema already covers instance details.

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

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

Schema coverage is 100%, so baseline is 3. The description adds a semantic nuance: passing an array fetches several comps in one call, clarifying batching behavior beyond the schema's type definition.

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

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

States a specific verb and resource: 'Detailed comp info' and enumerates the returned properties (size, fps, duration, work area, motion blur, layer summaries). It does not explicitly name sibling tools to differentiate, so not a 5.

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

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

No explicit when-to-use, when-not-to-use, or alternative-tool guidance. The description only covers parameter input (name/ID or array). The schema mentions calling ae_project_info first, but that context is absent from the description itself.

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

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

readOnlyHint=true already establishes the safety profile, and the description adds useful behavioral context by enumerating the returned payload and disclosing the undo contract (one auto undo group per call). It does not say anything about cost, size, or staleness of the returned context, which keeps it out of 5 territory.

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

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

Two tight sentences with the payload list front-loaded and the usage instruction following it; no filler. The list of context items is dense but each element earns its place by telling the agent what it gets back.

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

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

With no output schema, the description carries the return-value burden and does so by enumerating the context categories. Combined with a fully documented optional parameter and readOnlyHint, an agent has enough to call it correctly and interpret the result.

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

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

The single optional `instance` parameter is fully documented in the schema (100% coverage), including fallback behavior and where to list live instances. The description adds no meaning beyond that, so the baseline 3 applies.

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

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

Names the resource (ambient session context) and enumerates the concrete contents: project state, active comp, selected layers, item list, AE.* helpers, ES3 rules, and the undo contract. This clearly distinguishes it from narrower siblings like ae_project_info, ae_comp_info, and ae_layer_info, though it never says so explicitly.

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

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

'Call at session start; then rely on ae_do response context' gives a clear lifecycle rule for when to use it and when not to repeat it. It does not name the sibling info tools as alternatives, so it falls short of a full when/when-not/alternative statement.

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

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

The single destructiveHint=true annotation is far from the whole story, and the description fills the gap well: validation happens before AE is contacted, every call is wrapped in one undo group (whole call reverts with one Ctrl+Z), batch.run counts as one call, and the beginUndoGroup/endUndoGroup prohibition is stated. It stops short of describing failure/timeout behavior in detail, so not a 5.

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

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

Front-loaded with the core purpose and then layers on batching, undo semantics, the eval.run caveat, and the response note. Dense but each sentence carries actionable information; the trailing example is slightly long but earns its place by illustrating arg structure.

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

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

For a generic dispatcher over arbitrary operations with no output schema, this is complete: it explains where operation names come from, how args are validated, undo/batch semantics, the undo/redo exception, instance addressing, and that the response includes ambient context at no extra round trip.

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

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

Schema coverage is 100%, so parameters are already documented and the baseline is 3. The description nonetheless adds meaning beyond the schema: operation names are sourced from ae_catalog, args are validated against declared params (missing/wrong-type/unknown rejected), and the worked example shows the real args shape for keyframe.add.

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

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

States a specific verb and resource: 'Execute an atomic operation by name (from ae_catalog).' It clearly differentiates itself from siblings — ae_catalog lists/names operations, while ae_do executes them — and the inline keyframe.add example makes the role concrete without opening a schema.

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

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

Explicit routing rules: use ae_catalog for operation names, prefer ONE batch.run over several ae_do calls, and a stated exception (undo/redo run outside the undo group and cannot ride in a batch). This is genuine when/when-not/alternative guidance, not inference.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered and the bar is lower. The description usefully discloses the three access modes and the case-insensitive topic matching, but says nothing about result shape, topic granularity, or size of the knowledge base — the agent cannot tell how much text a read will return.

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

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

Front-loaded with what the knowledge covers, then the invocation modes, then the when-to-use guidance — a sensible order. The content enumeration in the opening sentence is long but each item signals a distinct capability an agent might need to locate.

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

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

With two optional params, full schema coverage, no output schema and readOnly annotations, nothing material is missing — the no-argument mode gives the agent a self-discovery path, so the absence of a topic listing in the description is not a gap.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds real semantics: that `query` spans every topic, that `topic` matches names as listed, and that omitting both yields a topic index. That is meaningfully more than the per-field schema strings provide.

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

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

States a specific resource and enumerates its contents (workflow rules, easing/timing, kinetic typography, PSD-to-animation, installed plugins/presets/MOGRTs, brand rules). This is clearly distinguished from the sibling probes (ae_comp_info, ae_layer_info) which return live app state rather than authored knowledge.

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

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

Explicitly gives the selection rule: no argument lists topics, `topic` reads one, `query` searches all, plus a when-to-use directive ('read the relevant topic BEFORE planning a non-trivial animation or choosing an effect'). This is exactly the when/when-not/alternatives pattern.

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

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

Annotations only declare readOnlyHint=true, so the description carries extra weight and delivers: it warns the full tree is often 100KB+ per comp and that includeProperties=false skips the property walk entirely. This is actionable performance/cost context beyond the structured fields. It does not cover auth or instance-resolution behavior, which the schema fields handle instead.

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

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

Four dense sentences, front-loaded with the returned content and then the scoping/size guidance; each clause carries information. Slightly long, but nothing is padding.

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

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

No output schema exists, and the description compensates by enumerating the returned structure, the size expectation, and the detail/includeProperties downgrades. Combined with 100% parameter coverage, an agent has enough to call it correctly; only the instance-resolution nuance and no explicit sibling routing leave minor gaps.

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

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

Schema description coverage is 100% and every parameter is already documented in the schema, so the baseline is 3. The description's layerIndex sentence largely restates the schema's anyOf (single index, array, 'all'), though it adds the audit rationale for batching. It adds little semantic detail the schema lacks.

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

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

States a specific verb+resource with an explicit enumeration of what is returned (transform, effects, masks, text, shape contents, keyframes with interpolation names). It is clearly distinguishable from siblings like ae_comp_info or ae_project_info. An agent can tell exactly what this call yields without opening the schema.

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

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

Gives real usage direction: use detail:'summary' to start audits, and 'all' to audit a whole comp in one round trip. It explains the flag trade-offs but never names or excludes a sibling tool, so it stops short of full alternative routing.

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

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

With only destructiveHint=false in annotations, the description carries most of the burden and does well: it discloses the disk-write side effect, that inline output may be large, and the full scope of what is serialized. It stops short of noting performance cost on large projects or any error behavior, keeping it below a 5.

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

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

Two tightly written sentences with zero filler. The scope enumeration leads, and the output-destination rule follows immediately, making it fully front-loaded.

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

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

There is no output schema, but the description compensates by enumerating the exact JSON contents (comps, layers, keyframes, effects, etc.) and flagging that inline responses can be large. Combined with a fully documented parameter schema, an agent has everything needed to call it correctly.

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

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

Schema coverage is 100% and all three parameters (pretty, outPath, instance) have thorough descriptions, so the schema does the heavy lifting. The description's mention of outPath vs inline is a restatement of what the schema already documents, adding no format or syntax detail beyond it — the baseline 3 is appropriate.

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

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

States a specific verb (serialize/export) and resource (entire project) and enumerates exactly what is captured — folders, comps, layers, keyframes, effects, shapes, markers, time remap, solids, file refs. This clearly distinguishes it from the inverse sibling ae_project_import_json and from ae_save_project, which persists rather than serializes.

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

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

Explains the mode selection rule — set `outPath` to write to disk, omit it to get the JSON inline — which is the key decision an agent must make. It does not, however, say when to prefer this over siblings like ae_project_info (summary) or ae_save_project (persist), so routing among related tools is left to inference.

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

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

Annotations already declare destructiveHint=true, and the schema fully documents clearFirst's destructive behavior and skipValidation's risk. The description's recitation of parameter names adds no behavioral context beyond the structured data, and says nothing about auth, instance defaults, or failure semantics.

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

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

Front-loads the core action and provenance in one clause, then lists flags tersely. Slightly fragmentary ('Supports ...'), but nothing wasted.

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

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

For a six-parameter mutation tool with no output schema, the description plus the fully-covered schema and the destructiveHint annotation cover what an agent needs to invoke it. It stops short of describing return/plan output or rollback behavior after a destructive clearFirst import.

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

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

Schema description coverage is 100%, so all six parameters (including the mutually-exclusive json/inPath pair and the instance addressing) are already fully documented in the schema. The description only restates three flag names, adding no meaning beyond 'dryRun (validate-only)' which the schema itself states.

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

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

States a specific verb+resource ('Rebuild the project from JSON') and explicitly identifies the producing sibling (ae_project_export_json), which no sibling tool list otherwise resolves. An agent can tell this is the inverse of the export tool.

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

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

The pairing with ae_project_export_json implies when to reach for this (round-tripping an export), and 'dryRun (validate-only)' hints at a pre-flight use. But there is no explicit when-not or guidance on choosing between inline `json` vs `inPath`, leaving usage to inference.

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

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

readOnlyHint=true already covers the safety profile, and the description adds real behavioral value by disclosing the return payload (dirty flag, item list with type/summary, active item) even though no output schema exists. It does not cover the multi-instance addressing behavior, but that is documented in the schema.

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

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

A single compact sentence listing the payload, followed by a two-word directive. No filler, and the enumerable content is front-loaded before the 'Start here' call to action.

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

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

For a zero-required-param, read-only info tool with no output schema, describing the returned fields is the key completeness requirement and it is met. The only gap is clarifying its position relative to the comp/layer info siblings, which 'Start here' only loosely implies.

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

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

Only one optional parameter and schema description coverage is 100%, so the detailed `instance` semantics live entirely in the schema. The description adds nothing about instance selection, which is acceptable at the baseline given full schema coverage.

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

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

The description names the resource (project) and enumerates exactly what is returned: file path, dirty flag, items with type/summary, active item. This distinguishes it implicitly from ae_comp_info and ae_layer_info, which are the comp- and layer-level counterparts, though it never names those siblings explicitly.

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

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

'Start here.' gives an implied entry-point hint, telling the agent this is a reasonable first call before drilling into comps/layers. There is no explicit when-not-to-use or named alternative, so guidance remains inferred rather than stated.

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

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

Annotations only carry destructiveHint=false; the description shouldered the rest and does well on execution traits (headless, deterministic, file naming, contact-sheet defaults). The color-management section is unusually candid about fallbacks and the `colorWarning` escape hatch. However, it omits cost/latency expectations for multi-frame renders up to 32 items and says nothing about mutation of disk state beyond created parent directories.

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

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

Purpose is front-loaded in the first clause, and each subsequent sentence covers a distinct decision (single vs multi-frame, contact sheet, analysis, color pipeline). It is a single dense paragraph of ~150 words that would scan faster as a short list, and the color-management sentence is long enough to bury its actionable tail.

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

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

With 11 parameters, a nested object, and no output schema, the description carries the response contract itself: it names `frames`, `analysis`, `colorPipeline`, and `colorWarning`, and explains what lands on disk. An agent has everything needed to call it correctly and interpret what comes back.

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

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

Schema coverage is 100%, so the baseline is 3; the description still adds value by explaining the interaction between `time`/`times` (mutually exclusive, index-aligned output), how `outPath` doubles as a naming stem, and why `colorManaged: off` yields dark/wrong-looking results. These are behavioral consequences rather than restatements, though much of the per-parameter detail is already in the schema.

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

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

Opens with a specific verb+resource+output format ("Render one or more frames to PNG") and immediately frames the intent with a metaphor plus a concrete use ("visually verify edits", "pair with mutations for a visual feedback loop"). This clearly separates it from the sibling info/context tools, none of which produce pixels.

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

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

Explicit routing rules: use `time` for one frame, `times` for several in ONE call for motion checks, `contactSheet` when a motion check should be one image, `analyze` when you want numeric checks instead of eyeballing. It also states the pairing pattern (mutations + render = feedback loop), so an agent knows when to reach for it.

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

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

Annotations already declare destructiveHint=true, so overwrite risk is flagged structurally, but the description adds no behavioral context of its own (no overwrite warning, no undo/irreversibility note, no permission requirements). With annotations carrying the safety profile, the description contributes essentially nothing beyond restating the name.

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

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

Two short sentences, zero filler, with the Save As affordance front-loaded. Nothing wasted.

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

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

For a simple two-parameter save tool with 100% schema coverage and a destructiveHint annotation, the definition is largely complete; the only real gap is that overwrite/irreversibility context is left entirely to the annotation rather than being reinforced in text.

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

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

Schema description coverage is 100% and the `path` description already explains the Save As behavior and the never-saved error. The description merely repeats a subset ('Pass `path` for Save As') without adding format or constraint detail, so baseline 3 applies.

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

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

States a specific verb and resource ('Save the project') and distinguishes the Save As variant via the `path` argument. Clear enough for an agent, though there is no need for sibling differentiation since no other tool in the list saves.

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

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

The line 'Pass `path` for Save As' implies when to supply the argument, but the description itself gives no when-not guidance or note about the failure case; that context lives only in the schema's parameter description.

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

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

The readOnlyHint annotation already establishes this is a safe read. Beyond that, the description discloses what the response reports (capability availability), which is decision-relevant for an agent choosing which APIs to attempt. It does not cover instance-resolution failure behavior, but the annotation carries the safety burden.

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

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

Two compact sentences: the first declares exactly what comes back, the second declares when to call it. No filler, no restatement of the title, and the highest-value information leads.

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

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

With no output schema, the description does the work of sketching the return payload (version, build, capability list), which is sufficient for a trivially simple zero-required-param info tool. Only minor detail, such as the shape of the capability list, is missing.

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

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

There is a single optional 'instance' parameter and schema coverage is 100%, so the schema already documents instance resolution thoroughly. The description adds nothing about parameters, so the baseline 3 applies.

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

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

The description names the exact resource contents (AE version, build, capability flags like saveFrameToPng, app.effects, Socket), which is far more specific than a tautology on 'Version info'. It implicitly distinguishes itself from info siblings such as ae_project_info or ae_comp_info by scoping to the host application itself rather than a document, though it never names those siblings explicitly.

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

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

'Call at session start to know what APIs are available' gives an explicit trigger condition, which is exactly the kind of when-to-call guidance most descriptions lack. There is no when-not or named alternative, so it stops 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.