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

Annotations already declare destructiveHint=true and openWorldHint=false, so the safety profile is partly covered, but the description adds nothing about what the creation mutates, how it interacts with existing layer order, or what happens when a group of the same name exists. For a destructive write with a surprising flag, staying silent leaves a real gap.

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

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

A single front-loaded sentence with no filler or repetition. It is tight, but the brevity comes at the cost of coverage rather than from disciplined editing.

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 tool has five parameters, two of which are non-obvious optional controls, plus a destructive hint that the description never addresses. An output schema exists so return values need not be explained, but key invocation details such as where the group is created and how parent_path is interpreted are absent.

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 0% across five parameters. Only "name" is weakly implied by "named group"; application, session_id, and especially parent_path (nesting target) and expected_parent_name (a guard condition) are completely opaque from both schema and description. This is the clearest failure of the 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?

The description names a specific verb and resource ("Create a named group"), which is better than a tautology, but the qualifier "for editable motifs or layered cartoon source parts" is domain jargon that does not clarify scope. It gives no signal distinguishing this from siblings like adobe_edit_layers or adobe_add_path, which also alter document structure.

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

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

There is no when-to-use guidance, no prerequisites (e.g. an open session / document), and no mention of alternatives such as adobe_edit_layers for modifying existing groups. The agent must infer entirely from the name when grouping is the right operation.

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=false and destructiveHint=true, so the write/destructive character is known from structured data. The description adds genuinely new context — the geometry is retained and editable in the document, and coordinates are px/pt measured from top left — but it does not mention what the operation mutates or requires (session_id, application, grouping), so added value is modest.

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

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

A single tight sentence with the core operation front-loaded and zero filler; the semicolon cleanly appends the coordinate convention rather than padding it.

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 destructive 8-parameter geometry mutation with an output schema, the description covers only the operation name and coordinate convention. Point structure, fill behavior, closing, grouping, and application/session targeting are left entirely to an undocumented schema, so an agent cannot reliably construct a valid call from the definition alone.

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?

With 0% schema description coverage across 8 parameters, the description must carry the burden and it largely does not: it explains only the coordinate units and origin. There is no explanation of the BezierPoint structure (anchor/left/right handles), rgb fill, closed, group_path, or expected_group_name, leaving most parameters semantically opaque.

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: 'Create retained editable Bézier geometry, optionally filled.' That clearly separates it from shape/rectangle or text insertion siblings, though it never names an alternative like adobe_add_rectangle, so the differentiation is implied rather than explicit.

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

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

The phrase 'editable Bézier geometry' hints at when to use this over simpler primitives, but there is no explicit when-to-use/when-not guidance and no sibling is named as the alternative for simpler shapes.

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 readOnlyHint=false, so the safety profile is known. The description adds one genuinely non-obvious behavioral fact — that the shape lands on a new layer — but says nothing about the effect of opacity, whether an existing selection or clipping applies, or what happens if a layer name collides.

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

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

One compact sentence with the operation front-loaded and the argument-format clarification after the semicolon. No filler or restated title.

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?

An output schema exists, so return values need not be explained, but for a 6-parameter mutation with 0% schema coverage the description leaves most parameters and all preconditions unexplained. An agent knows how to place the rectangle but not what name, rgb or opacity do.

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 0%, so the description must compensate, and it does for the most error-prone parameter by defining bounds as x,y,width,height in px/pt. The other five parameters (name, rgb triple, opacity, session_id, application enum) get no explanatory text, so the compensation is only partial.

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 gives a specific verb+resource ("add a filled motif or mask on a new layer") and the bounds format, which is enough to separate it from add_text, add_path and add_group. The term "motif or mask" is looser than the tool name's "rectangle", but the intent (a filled rectangular shape) is still recoverable.

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

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

There is no statement of when to use this versus alternatives such as adobe_add_path for outlines or adobe_apply_mask for masking existing layers, and no prerequisites (open document, session) are mentioned. Usage has to be inferred from the verb alone.

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 openWorldHint=false, so the safety profile is partly covered. The description adds that the resulting text is editable and native (non-rasterized), but says nothing about what the destructive flag means here — whether it overwrites an existing layer, whether the action is undoable, or what the returned value represents despite an output schema existing.

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, tightly written sentence with the key qualifier front-loaded and no filler. It is efficient, though the brevity tips into under-specification rather than elegant economy.

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 8-required-parameter, zero-coverage destructive creation tool, the description is far too thin — it documents only two of the parameters and omits coordinate system, color range, and any preconditions. An output schema exists so return values need not be explained, but the invocation-critical gaps remain substantial.

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 0% across 8 required parameters, so the description carries the full burden and only partially meets it: it clarifies that 'font' must be an exact discovered PostScript name and that 'size' is a point size. It says nothing about the 'position' array format/units, 'rgb' value range, 'name' semantics, or 'session_id'/'application' requirements.

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: 'Create editable native text', and adds two defining constraints (exact discovered PostScript font, point size). This is clearly distinct from siblings like adobe_add_rectangle or adobe_place_image, though it does not name 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?

There is no explicit when-to-use guidance, no statement of prerequisites or ordering, and no mention of which application (photoshop vs illustrator) scenarios it applies to. The word 'discovered' only weakly hints that a font must first be looked up via adobe_fonts; the agent must infer this.

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, readOnlyHint=false, and openWorldHint=false, so the safety profile is known. The description adds only the outcome semantics per application; it never says whether an existing mask or clipping group is replaced, what happens on failure, or whether the target layer must be selected or active.

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 zero filler; the application-conditional outcome is packed into one clause. Nothing to trim.

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 destructive five-parameter mutation with an output schema, so the description needn't explain returns, but it should cover preconditions and the meaning of expected_name and layer_path. With 0% schema coverage, one sentence leaves an agent guessing how to build a valid call.

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 0% and all five parameters are required with no inline documentation. The description maps loosely to path_name ('named path') and application (PS vs Illustrator), but layer_path's integer index array, expected_name's verification role, and session_id are left entirely unexplained.

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

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

States a specific verb (apply) and resource (retained named path) and spells out the application-dependent result: a Photoshop layer mask versus an Illustrator clipping group. This is enough for an agent to distinguish it from adobe_add_path, which creates paths rather than consuming them, though no sibling is named in the text.

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 never says when to use this versus alternatives, nor does it state the obvious precondition that a named path must already be retained in the document. The word 'retained' hints at a dependency but no guidance is given on obtaining or verifying that path first.

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 disclose destructiveHint=true and readOnlyHint=false. The description adds meaningful scope: it saves before closing and targets only the cooperative copy, not original documents. It could be stronger by mentioning unsaved-state handling or failure conditions, but it adds real context 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?

The description is a single front-loaded sentence with no filler. The term 'cooperatively owned copy' is somewhat jargon-heavy but the scope constraint comes through clearly. It is appropriately sized for a simple close operation.

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 output schema exists, so return values need not be explained, and annotations cover the destructive safety profile. However, with two required parameters at 0% schema description coverage, the description omits parameter guidance needed to invoke the tool correctly. It is adequate on scope but incomplete on invocation context.

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 0% for two required parameters, and the description provides no explanation of session_id or application. It does not clarify that application must be photoshop or illustrator, nor what session_id identifies. This leaves the agent dependent on bare parameter names.

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 uses a specific verb+resource: 'Save and close' a 'cooperatively owned copy'. It also distinguishes the target from 'original documents', which helps separate it from broader document-closing behavior. It does not explicitly name the sibling adobe_open_copy or clarify the relationship, 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 implies usage by limiting the tool to the exact cooperatively owned copy and excluding original documents. However, it does not state prerequisites such as needing an active cooperative session or name alternatives like adobe_operation_control. The guidance is useful but incomplete.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=false, so the description only needs to add context beyond that. It usefully discloses fixed output traits (transparency, 72 ppi, sRGB) but says nothing about where the canvas is created, whether it opens a document window, or what happens if width/height exceed limits.

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; each clause (transparency, 72 ppi, sRGB, bit depth) conveys a real specification. It is arguably too terse rather than padded, which is a completeness issue rather than a conciseness one.

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 required, entirely undocumented 'destination' parameter and no explanations in the schema, the description leaves a critical gap. An output schema exists, so return values need not be described, but the input contract is not self-sufficient.

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 0%, so the description must carry parameter meaning, and it largely does not. The 'default depth is 16-bit' note merely repeats the schema default, while the required 'destination' parameter is never explained, and width/height units and their 2880 cap are left to the schema.

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

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

The description gives a concrete verb and resource ('Create a ... Photoshop canvas') and pins the output profile (transparent, 72 ppi, sRGB), which distinguishes it from siblings like adobe_place_image or adobe_add_rectangle. It does not explicitly contrast itself with any sibling, but the create-canvas purpose is unambiguous.

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

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

There is no guidance on when to use this versus alternatives, no prerequisites, and no indication of what happens after creation (e.g., whether the canvas becomes the active document). The agent must infer usage entirely from the verb.

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 readOnlyHint=false, so the mutation risk is known. The description adds genuinely new context by signalling optimistic concurrency ('expected names') and copy scoping, but it never explains what happens on a name mismatch, whether the 64-edit batch is atomic, or whether partial edits are applied before failure.

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 the mutating verbs first and the scoping condition last; nothing is padded. Density is high enough that some terms ('exact paths with expected names') are underexplained, which keeps it from a 5.

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 tool is a destructive batch mutation over a nested edit list with an output schema, yet the description omits prerequisite session/copy setup, mismatch failure behavior, and batch atomicity. For a destructive multi-edit operation, these omissions leave an agent unable to predict outcomes on error.

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 0%, so the description must carry parameter meaning. It maps loosely to three nested fields (name for rename, visible for hide/show, opacity) but leaves path, expected_name, session_id, and the application enum completely unexplained, and mentions none of the cardinality limits.

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 specific operations (rename, hide/show, opacity) on a specific resource (layers addressed by path) and scopes the target to an owned copy, which distinguishes it from sibling creation tools like adobe_add_group. It falls short of a 5 because 'exact paths with expected names' is opaque phrasing that only becomes meaningful once the schema is read.

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 'in an owned copy' implies a precondition (work on an open copy rather than the original), but the description never states that adobe_open_copy must run first, nor does it contrast with siblings such as adobe_add_group or adobe_inspect. Usage is inferable rather than stated, and no when-not guidance is offered.

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 annotations already indicate this is not read-only, non-destructive, and closed-world. The description adds the useful default behavior that Photoshop exports PNG and Illustrator exports SVG unless PNG24 is explicitly requested, but it does not disclose how destination files are handled, whether overwrites occur, or what file-system effects the export has.

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 front-loaded sentence with no wasted wording. However, terms such as 'native-depth' and 'PNG24' are compressed to the point of ambiguity, so brevity comes at some cost to clarity.

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 tool has five parameters with zero schema description coverage, and the description leaves most of them unexplained. Although an output schema exists and annotations cover safety hints, the definition is still missing key behavioral and parameter context needed to call the tool correctly.

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

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

Schema description coverage is 0%, so the description should compensate for five undocumented parameters. It hints at the relationship between application and default format selection, but it does not explain destination, usage, session_id, or the exact meaning of the kind enum and PNG24 behavior.

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 a specific action (export) and identifies the default output formats for Photoshop and Illustrator. It is understandable at a high level, but it does not clearly distinguish this tool from siblings such as after_effects_render or explain the full scope of the export operation.

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 states a default format behavior but gives no explicit guidance on when to use this tool versus alternatives. It does not cover when to choose PNG24 explicitly, when to prefer vector SVG, or any prerequisites for exporting.

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 annotations already declare read-only, idempotent, closed-world, non-destructive behavior, so the safety profile is fully covered. The description adds that output includes exact PostScript names, which is useful, but it never states the required application parameter or any scoping/limit behavior.

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

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

One front-loaded sentence with no filler, and the most important output detail (PostScript names) lands immediately. It is arguably too short rather than too long.

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

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

For a tool whose only parameter is required and completely undocumented, and whose listing is presumably per-application, the description omits the one fact an agent must know before calling it. The output schema covers return values, so that omission is acceptable, but the input scoping gap is not.

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 0% and the single required parameter ("application", enum photoshop|illustrator) has no documented meaning anywhere. The description never mentions that an application must be supplied or what selecting one changes about the returned font set, so it fails to compensate for the schema gap.

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 gives a specific verb+resource ("List native font families, styles and exact PostScript names") and is unmistakably distinct from every sibling, none of which touch fonts. It stops short of saying the listing is scoped to a single application, which is the one qualifier an agent needs.

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

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

There is no when-to-use or when-not-to-use guidance and no named alternative. The only implicit signal is that the result is useful when the agent needs font identifiers, which an agent must infer on its own.

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, idempotentHint=true and destructiveHint=false, so safety is covered. The description does add one genuinely non-obvious behavioral fact: an unrecognized command blocks subsequent mutations, which warns of a side-effect on the session. But 'command' is undefined (the schema only has 'application' and 'session_id'), so the warning is hard to act on.

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

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

It is a single compact sentence with the read purpose front-loaded, so there is no padding. The trade-off is under-specification rather than verbosity: the trailing clause is cryptic and would benefit from one clarifying sentence naming what 'command' refers to.

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?

An output schema exists, so return values need not be described, and annotations carry the safety profile. Still, for a tool with a required enum parameter and an undocumented optional session handle, the description leaves key call-time questions unanswered and is too thin relative to its sibling set.

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 0% and the description names neither parameter. It never explains that 'application' is a required enum of photoshop/illustrator, nor what a null 'session_id' means (presumably a default session). With no schema documentation, the description needed to compensate here and does not.

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 verb 'read' plus the resource 'native document/layer identities' gives a rough sense of an inspection tool, and it is distinguishable from mutation siblings like adobe_edit_layers or adobe_export. However, 'identities' and 'native' are never defined, so an agent cannot tell whether this returns document IDs, layer names, or internal handles. The second clause about 'an unknown command' muddies rather than sharpens the purpose.

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

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

There is no explicit statement of when to call this versus adobe_status or the other read-oriented siblings, and no prerequisites are named. The only implicit cue is that it is a read operation, which the annotations already say. The phrase 'blocks later mutations' hints that it should precede edits, but this is left for the agent to infer.

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=false, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds that it creates a copy and requires a new destination, but omits permissions, error behavior if the destination exists, and what 'owned' implies.

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 purpose and key constraint front-loaded, and no wasted wording. Terms like 'owned' and the 'workspace PSD/AI/PNG/SVG' notation are slightly jargon-heavy but not verbose.

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 output schema covers return values and annotations cover safety, so the description need not repeat those. It still leaves meaningful gaps around source/destination semantics and sibling alternatives, which matter for a three-parameter file-creation tool.

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

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

Schema description coverage is 0%, so the description must compensate. It hints that source is a workspace file in PSD/AI/PNG/SVG, application corresponds to PSD/AI, and destination must be new, but gives no path syntax, validation rules, or extension expectations.

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 action (open a new owned copy) and resource (PSD/AI copy), including source workspace formats and the destination constraint. It does not differentiate from siblings such as adobe_close_copy or adobe_create_canvas, 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 explicit when-to-use or when-not-to-use guidance and names no alternatives. The only guidance is the constraint that the destination must be new, leaving the agent to infer that this is for starting a fresh copy rather than editing an existing file.

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 readOnlyHint=false, so the safety bar is lower. The description adds genuine context beyond them: adopt requires 'both observed hashes' and abandon is only valid 'after app exit'. It does not clarify that the inspect action is a safe read within an otherwise destructive tool, nor what state is lost on abandon.

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 with the three actions front-loaded, which is the right shape. The compression goes too far, though — 14 words of dense noun phrases leave the actor and resource ambiguous rather than merely brief.

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?

Output schema exists so return values need not be described, but a 6-parameter, destructive, stateful operation-control tool with 0% schema coverage needs far more than one sentence. The three required identifiers are undocumented and the destructive action's consequences are unstated.

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 0% across 6 parameters, so the description must carry the load, and it only partially does: 'with both observed hashes' ties the two sha256 fields to adopt_current but never says whether they are mandatory there or what the observed/expected distinction means. session_id, application, and operation_id get no explanation at all.

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 three distinct actions (inspect, adopt, abandon) that map to the action enum, but the object of those verbs — 'retained completion' — is opaque jargon that an agent cannot resolve without guessing. It never contrasts itself with the very similar siblings adobe_inspect, adobe_open_copy, and adobe_close_copy, so the agent cannot tell which tool owns this behavior.

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

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

There is only an implicit sequence ('inspect ... adopt ... or abandon after app exit') with no explicit statement of when to pick this tool over adobe_inspect or adobe_close_copy. No preconditions are spelled out, no exclusions, no guidance on which action applies to which situation beyond the ordering hint.

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 annotations already establish a non-read-only, destructive operation, and the description adds useful context about the existing source and application-dependent coordinate units. It does not explain how placement modifies the document, whether anything can be overwritten, or what session or group prerequisites affect execution.

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

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

The single sentence is compact and front-loads the operation and target. The coordinate-unit detail is directly useful, with no redundant or filler wording.

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 output schema removes the need to describe return values, but invocation remains under-specified for a destructive seven-parameter tool. Source handling, group identification, session prerequisites, and the optional group-related fields are not sufficiently explained.

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 description clarifies that the source is an existing PNG and that position represents x/y in Photoshop pixels or Illustrator points. With 0% schema description coverage, it leaves too much unexplained: the accepted source location format, the role of name, session_id, group_path’s integer indices, and expected_group_name.

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 specifies the action (embed), resource (an existing PNG), and destination (a named group). It does not explicitly differentiate this operation from the other Adobe editing or import-related siblings.

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?

“Existing PNG” and “named group” imply that this is for placing prepared image content into an existing structure. There are no explicit prerequisites, when-not conditions, or alternatives such as creating a group first or using another editing tool.

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 annotations already establish that this is read-only, idempotent, non-destructive, and closed-world. The description adds the useful behavioral constraint that it will not launch applications or use Apple events, but it does not explain what status information is checked or what conditions cause an app to be reported as installed or running.

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 definition is a single short sentence with no filler. The scope and behavioral exclusions 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?

The tool is simple, the annotations are rich, and an output schema exists, so the description need not explain return values in detail. It is nearly complete for this complexity level, though it would be stronger if it explicitly connected the 'application' enum to the inspection behavior or named the closest sibling alternative.

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 parameter has 0% schema description coverage, so the description should compensate by explaining the accepted values or their meaning. It does not mention the 'application' parameter at all, although the enum values 'photoshop' and 'illustrator' make the schema partly self-explanatory.

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 uses a clear verb, 'Inspect,' and specifies the resource area, 'installation and running process.' The phrase 'only; no app launch or Apple events' helps distinguish this status-checking tool from sibling tools that open, create, edit, or render Adobe documents.

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 a useful boundary by saying this is inspection only and does not launch apps or send Apple events. However, it does not explicitly say when to use this instead of related siblings such as adobe_inspect or adobe_open_copy, so the usage guidance remains implied rather than fully actionable.

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?

Beyond the annotations (which only say not read-only, not destructive, not open-world), the description discloses concrete runtime behavior: a 300s/8GiB cap, launching an external aerender process, isolation from the artist's AE instance, writing into a new directory, and aborting on license/account prompts. It does not say what state is left behind on timeout or failure, but the operational profile is unusually well disclosed.

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?

Dense and front-loaded: the core action and its limits open the description, with constraints following. A few lines are cryptic or marginally relevant (e.g. 'Never reuses an artist's AE instance'), but there is little filler.

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?

Return values are covered by the output schema and the resource caps are stated, but for a tool whose only required input is an opaque 'recipe' the description leaves the most consequential detail — the recipe format and failure semantics — unaddressed. Adequate for calling, not for calling correctly on the first try.

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 0% and both parameters are undocumented strings. The description hints at content (recipe carries dependencies, FPS and output-module declarations; directory is a new PNG destination) but never specifies the recipe's encoding or structure, so an agent still cannot construct a valid value from this text.

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 first sentence gives a specific verb and resource — launch aerender for one declared AEP comp/range into a new PNG directory — with scope limits. It is unmistakable what the tool does, though the abstract 'recipe' concept is not defined, leaving the mechanism slightly opaque.

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 states preconditions (caller must supply timing/dependency declarations, recipe must declare dependencies, FPS and an existing straight-alpha RGBA PNG output module) and a stop condition (license/account prompt). It does not say when to prefer this tool over another or what to do if the preconditions are not met, so usage is implied rather than directed.

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=false, destructiveHint=false and openWorldHint=false; the description corroborates localness ('free local') and adds genuine behavioral detail not in annotations: that MOV output preserves alpha while MP4 explicitly composites onto black, which materially affects output correctness. It still omits what gets written where and any failure/side-effect behavior for the pinned frames, but the alpha/compositing disclosure is real added value.

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; the codec consequence is stated compactly with a semicolon. It is dense with unidentified jargon ('pinned frames', 'receipt'), which trades clarity for brevity, but nothing is redundant.

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?

An output schema exists, so return values need not be explained, but for a 3-parameter tool with zero schema descriptions the definition leaves key call-blocking gaps: what a 'receipt' is or how to obtain one, what 'directory' refers to (source vs destination), and whether a file is written. Only the codec dimension is adequately covered.

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 0%, so the description must compensate for three undocumented parameters and does so only partially. The MOV/MP4 sentence implicitly maps to the codec enum (prores_alpha vs h264_black) but never names or maps the enum values explicitly, and 'receipt' and 'directory' — two of three parameters, both required — get no explanation whatsoever.

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 a concrete mechanism (local FFmpeg/ffprobe over pinned frames) and a concrete output distinction (MOV alpha vs MP4 black), which separates it from siblings like after_effects_render and adobe_export. However, it never plainly states that the tool produces/encodes a movie file from a receipt, and terms like 'pinned frames' and 'receipt' are left undefined, so the core purpose is only inferable.

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

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

There is no explicit guidance on when to choose this tool over after_effects_render or adobe_export, nor on prerequisites (does a render/receipt need to exist first?). The MOV-vs-MP4 note is really codec-choice guidance for a parameter, not when-to-use guidance, leaving the agent to infer selection criteria.

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