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

No annotations are provided, so the description carries the full disclosure burden. The word 'check' plus latency measurement conveys a diagnostic, non-mutating operation, but the description never says whether an unreachable bridge raises an error or returns a status value, nor whether it is cheap enough to poll — critical details for an agent deciding whether to gate other calls on it.

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

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

A single front-loaded sentence with no filler; both the reachability check and the latency measurement are stated up front.

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

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

For a zero-parameter, annotation-free tool with no output schema, the description should at minimum sketch the return shape (reachable/not reachable, latency value) and failure behavior. It covers the what but leaves the result contract entirely unspecified.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline 4 applies.

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

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

States a specific verb (check reachability) and two concrete targets (After Effects and the MCP Bridge panel), plus a secondary function (round-trip latency). It is clearly distinct from sibling tools like render-status, which tracks render progress, though the description does not name that sibling to draw the contrast 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?

Usage is only implied: the agent can infer this is a pre-flight connectivity check before calling run-script or start-render, but nothing states when to call it, whether to call it before every operation, or what to do if it fails.

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

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

No annotations are provided, so the description carries the full behavioral burden, yet it says nothing about whether cancellation is immediate or graceful, whether partial output is discarded, whether it is idempotent on finished jobs, or what permissions are needed. It only restates the mutation implied by 'stop'.

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

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

One short sentence, front-loaded with the action and resource, with zero filler. Nothing could be removed without losing meaning.

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

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

For a one-parameter tool whose schema is fully documented, the essentials are present, but with no annotations and no output schema the description should at least describe the effect of cancellation and the expected result. It is adequate but leaves meaningful gaps.

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

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

Schema coverage is 100% and the single jobId parameter is documented as coming from start-render, matching the description. The description adds no further syntax or format detail beyond the schema, which is the expected baseline here.

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

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

Specific verb (stop) plus resource (a background render), and it ties itself to the sibling that creates such jobs (start-render), which separates it from render-status and render-frame. It doesn't explicitly contrast against other siblings, but the intent is unmistakable.

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

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

The phrase 'started by start-render' implies the precondition for use, but there is no explicit guidance on when not to call it, what to do if the job already finished, or how it relates to render-status. Usage is inferable rather than stated.

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

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

No annotations are provided, so the description carries the burden. It discloses that the tool creates a new composition but doesn't mention default behavior (e.g., default duration/frameRate if omitted) or whether it overrides an existing comp. The schema provides defaults for some parameters, but the description adds no extra behavioral context. Since creation tools are generally non-destructive (new resource), the lack of warning is acceptable, but the description could mention that existing comps are not affected.

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

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

The description is a single sentence with no filler words. It is front-loaded with the action ('Create') and resource ('a new composition'), making it immediately clear. Every word serves a purpose, and it is neither verbose nor under-specified.

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 creation tool with a rich schema (7 parameters, all documented), the description doesn't need to explain return values (no output schema). It could mention that the composition is added to the project panel or the current project, but this is implied by 'in After Effects.' The lack of annotations and output schema lowers the burden, but the description could be a bit more explicit about the context (e.g., the composition is created in the active project). Overall, it is minimally complete but not exceptional.

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 schema already documents all 7 parameters thoroughly. The description's phrase 'specified parameters' is generic. Consequently, the description adds no extra meaning beyond the schema. A baseline 3 is appropriate since the schema does the heavy lifting.

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

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

The description states the verb ('Create') and resource ('a new composition in After Effects'), which clearly identifies the tool's function. It doesn't distinguish from sibling tools explicitly, but siblings like 'create-adjustment-layer' are different enough that no confusion is likely. A more specific mention of parameters like width/height/duration would strengthen it, but the current wording is adequate.

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

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

The description gives the context ('Create a new composition in After Effects') but no explicit when-to-use or alternatives. It implies that this is the go-to tool for creating comps, especially since siblings don't include another composition creator. However, no prerequisites or exclusions are mentioned, making it minimally adequate.

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

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

No annotations are provided, so the description carries the full burden. It only restates the purpose ('Get help') without disclosing what the help output contains, whether it lists commands, returns usage examples, or requires further input. Behavior is largely opaque.

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?

Single sentence of 11 words, front-loaded with the verb 'Get'. No filler or redundancy; every word earns its place.

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

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

For a zero-parameter help tool, the description is largely complete, clearly stating the scope ('After Effects MCP integration'). The absence of an output schema means a description of the return format would have been useful, but this is a minor gap given the simplicity.

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

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

The tool has zero parameters and the schema is an empty object with 100% coverage. No parameter documentation is needed; the baseline for 0-param tools is 4, and the description doesn't misrepresent any parameters.

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 states 'Get help on using the After Effects MCP integration', with a specific verb and resource. It distinguishes itself from sibling tools that perform specific operations like apply-effect or run-script.

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 implied usage is when the user needs assistance with the MCP integration, but there is no explicit when-to-use guidance or mention of alternatives. It doesn't reference more specific help tools like mcp_aftereffects_get_effects_help.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses the return format as a PNG image, but it does not mention side effects, permissions, expected latency, or the render-method fallback behavior described 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?

The description is a single focused sentence with the primary action front-loaded and no wasted clauses. It communicates the purpose and output format efficiently.

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

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

The core operation and return type are stated, which is useful with no output schema. However, for a tool with five optional parameters and no annotations, the description does not clarify that a composition identifier is needed in practice or explain the method fallback behavior.

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

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

Schema description coverage is 100%, so all five parameters are already documented in the schema. The description adds no parameter-level detail, which is acceptable at the baseline when the schema does the heavy lifting.

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

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

The description states a specific verb and resource: render a single frame of a composition and return it as a PNG image. It clearly implies a narrower scope than start-render, but it does not explicitly name or contrast with any sibling 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 phrase 'so results can be verified visually' implies the intended use case, but there is no explicit guidance on when to choose this over start-render, run-script, or render-status. The agent must infer the selection criteria.

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

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

No annotations are provided, so the description carries the burden. It usefully discloses the session-scoping constraint (only jobs from this session are visible), but says nothing about return shape, whether jobs persist after completion, or whether polling is expected for a tool whose whole purpose is progress tracking.

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

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

A single front-loaded sentence that establishes the resource and its scoping constraint with no filler; the parenthetical naming the alternative entry point is worth its space.

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

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

For a simple one-optional-param read with full schema coverage and no output schema, the core is covered, but the agent is left guessing what 'progress' looks like in the response and whether completed jobs remain queryable.

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 one optional parameter at 100% schema coverage, with the schema already stating 'omit to list all jobs'. The description adds no further detail on jobId format or listing behavior, 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 a specific resource (background render progress) and pins it to jobs started by start-render / run-script startRender in this session, which separates it from render-frame and start-render. It lacks an explicit verb ('retrieve/report'), but the scope is unambiguous.

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

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

The reference to start-render and run-script startRender implies the follow-up role this tool plays after launching a job, and 'from this session' implies a boundary. There is no explicit statement of when not to use it (e.g. completed/older jobs) or what to do instead.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses synchronous execution over a local socket to the MCP Bridge panel, but it omits important traits for a command-execution tool, such as side effects, permissions, error behavior, timeouts, or whether arbitrary scripts can be run.

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, front-loads the primary action, and includes execution context without unnecessary filler. Every sentence contributes useful information.

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

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

This is a command-execution tool with no annotations, no output schema, and a nested parameters object. The description explains the transport mechanism but does not describe the result format, error handling, safety constraints, or when the tool should be preferred over more specialized sibling tools.

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

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

Schema description coverage is 100%, so the schema already defines both parameters, including the required script name and optional parameters object. The description adds little beyond the schema and does not explain how script names are discovered or how the parameters object is used.

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

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

The description states a clear verb and resource: run a command in After Effects and return its result. It does not explicitly differentiate this generic script runner from siblings such as render-frame, start-render, or create-composition, so it falls short of a 5.

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

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

The description gives no guidance on when to use this tool versus alternatives like render-frame, start-render, or create-composition. It also does not state exclusions or prerequisites, 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?

With no annotations, the description carries the burden and does well: it discloses that rendering happens out-of-process in the background, that it operates on the on-disk saved project, that unsaved changes cause a refusal unless saveProject is set, and that it returns an async jobId. It stops short of error behavior, concurrency limits (can two renders overlap?), or how cancellation interacts with cancel-render.

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?

Three short sentences with zero filler; the core action and the responsiveness benefit are front-loaded, followed by the project-file constraint and then the return value.

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 an async, no-output-schema tool the description covers what an agent needs to call it and what comes back (jobId for render-status). Minor gaps remain: prerequisites such as aerender availability, what happens if a render is already running, and failure reporting.

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 both parameters are already documented in the schema, giving a baseline of 3. The description reinforces saveProject's consequence ('renders the SAVED project file'), but adds no detail about itemIndices ordering, out-of-range behavior, or partial selection.

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

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

Names a specific verb and resource ('Render the render queue') plus the underlying mechanism (aerender as a separate AE process), and implicitly separates it from the single-frame sibling render-frame. It also states the unit of work (the whole queue / default every item) and the return value (jobId).

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 rationale ('so After Effects and the bridge stay responsive') implies this is the non-blocking way to render a queue, but there is no explicit when-to-use versus render-frame, run-script, or the fact that you must poll render-status afterwards. The only concrete directive is behavioral (renders the SAVED file), not a usage rule.

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