AppScreenStudio

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 is a mutation ('Add'), yet it discloses no side effects, no ordering/z-index behavior, no permission requirements, and no indication of what is returned or what happens on failure. The only behavioral hint is the cropping behavior of spriteCoordinate.

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, front-loaded with purpose, then parameter guidance. No filler; every sentence 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 an 8-parameter tool with a nested object and no output schema, the description is only partially complete. The required screenshotId is undocumented in both the schema and the description, and the coordinate/positioning model lives entirely in the schema, leaving gaps an agent must infer.

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 75%, and the description adds genuine value for the two parameters the schema leaves bare: src (an image URL, sourced from upload_image/list_library) and spriteCoordinate (crops a single pose). It goes beyond the baseline of 3 by explaining the source of src and the intent of the crop object.

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: 'Add an image layer to a card.' An agent can tell this apart from add_text, add_div, and add_platform_set. It does not explicitly distinguish itself from add_screenshot, which is the closest sibling, 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?

It routes the agent for sourcing src ('such as one from upload_image or list_library') and names the condition for spriteCoordinate ('to crop one pose of a sprite sheet'). However, it never says when to use add_asset versus add_screenshot or generate_asset, so usage is only implied 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 full behavioral burden. It does disclose meaningful traits – that visible styles must live in the html, that backgroundColor/borderRadius only affect plain boxes, and that a <style> element stays scoped inside the card – but says nothing about mutation semantics, reversibility, or limits on the resulting layer, leaving real gaps for a write operation.

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 tightly packed sentences with no filler, front-loaded with the core action and then the customization mode. The one weak spot is a slightly abrupt trailing clause about the style element, but overall it reads 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?

For a 14-parameter mutation tool with no output schema and only 71% schema coverage, the description covers the central html workflow well but omits orientation info (opacity, rotations) and any return/result expectations. It is adequate but not complete.

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 71%, so most parameters are already documented in the schema, and the description adds useful context about how width/height define the layout box and how they interact with html. It adds nothing for the undocumented parameters (opacity, borderRadius, backgroundColor, screenshotId), so it only marginally compensates for the coverage 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 states a specific verb and resource: 'Add a box layer to a card,' and the html sentence clarifies it is the freeform-HTML card primitive. It implicitly separates itself from add_text/add_phone (text/phone layers) but never names those siblings outright, so it stops 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?

It gives conditional guidance for two modes – pass html to draw a custom card, or omit it for a plain box styled by backgroundColor/borderRadius – which implies when each path applies. However, it never names an alternative tool or states when to prefer add_div over add_text, add_screenshot, or update_div, leaving routing 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 behavioral burden and does reasonably well: it discloses defaults (platform set's device frame, positioned next to the main phone inheriting its size, rotation, shadow), z-order ('extra phones paint above the main phone, in the order they were added'), and the return value. It omits permissions/auth or mutation risk context, so it is not exhaustive.

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?

Five tight sentences, front-loaded with the core action, then defaults, an input hint, paint order, and the return value. Every sentence adds distinct information and there is no filler despite the parameter complexity.

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?

Given no annotations and no output schema, the description compensates by stating the return value (phoneId) and default behavior, which is helpful. However, with 36 parameters it leaves the majority of the parameter surface unexplained, so it is adequate but not complete for a tool of this complexity.

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

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

Schema description coverage is only 36% across 36 parameters, so the description must compensate but largely does not. It adds meaning only to imageUrl (upload_image hint) and implicitly to deviceId/color defaults, leaving the large focusOverlay*, shadow*, and fade families undocumented in both places.

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 ('Add') and resource ('another phone to a screenshot card in the open editor'), and clarifies it is a secondary phone distinct from the main phone. It does not explicitly name the sibling tools it contrasts with (update_phone, remove_phone, add_screenshot), so it falls just short of full sibling differentiation.

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?

Provides clear context for use: it must be applied in the open editor to a screenshot card, and imageUrl should come from upload_image with type screenshot, a useful cross-tool referral. No explicit when-not guidance or exclusion conditions are given, keeping it below a 5.

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, yet it only implies mutation via 'Add'. It does not say whether this requires an open project to exist, what happens on duplicate platform sets, whether the operation is reversible, or what the response contains.

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 short sentence with no padding, so it is concise, but it is under-specified rather than efficient — brevity here comes at the cost of informativeness.

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 two-parameter mutation tool with no annotations and no output schema, the description is inadequate: it explains neither the parameters, the behavioral consequences, nor the prerequisite of an open project. An agent has almost nothing beyond the schema to work with.

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 mentions no parameters at all — neither the required 'platform' enum (ios/android/social) nor the optional 'name'. The description adds zero meaning beyond the raw schema, which is a serious gap at this coverage level.

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 verb ('Add') and a resource ('platform set'), which is more than a tautology, but 'platform set' is undefined domain jargon and the description does nothing to distinguish this from sibling remove_platform_set. An agent knows roughly what happens but not what the entity actually is.

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, and no mention of the remove_platform_set sibling or any alternative. The only context is the phrase 'to the open project', which is a scope statement rather than usage guidance.

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 burden. It usefully discloses what the added font enables (fontFamily/font-family usage) and that it attaches to 'the open project', but says nothing about permissions, idempotency of duplicate adds, failure modes for unknown families, or persistence across sessions.

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, purpose front-loaded, with the follow-up usage and the scope exclusion following in logical order. No filler 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 single-parameter add tool with no annotations and no output schema, the description covers purpose, post-conditions, and scope. It could mention the return value or duplicate-handling, but it is largely sufficient to call 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%, so the 'family' parameter is already documented with an example ('such as Caveat'). The prose only reinforces that the name comes from search_google_fonts, adding little beyond the schema's own description. 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 ('Add a Google Fonts family to the open project') and immediately delineates scope by noting built-in editor fonts are excluded. An agent can distinguish it from search_google_fonts (discovery) and the many add_* siblings (assets, divs, phones).

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 a clear downstream use case ('use it as fontFamily on text layers or as font-family in card html') and an explicit exclusion ('Built-in editor fonts need no adding'). It implies the search-first workflow by naming search_google_fonts, but does not explicitly state the ordering or when this call must be skipped.

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 burden and does so well: it discloses the non-obvious behavior that the new card is not blank (first three cards inherit template sample texts and phone placement, later cards copy every layer of the last card minus its phone image) and states the return value. It omits permission/error behavior, 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?

Three sentences, front-loaded with the core action, then the generation behavior, then the return value. Dense but each sentence adds real information; no filler or repetition.

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 and no annotations, so the description must cover both behavior and returns, and it does (layer ids returned for later update/removal) plus the surprising template-copy logic. The remaining gap is the undocumented platformSetId, which is minor against the otherwise complete behavioral picture.

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 the single parameter platformSetId is undocumented in the schema. The description alludes to 'the set' but never defines what platformSetId is, its format, or how to obtain a valid id, so it does not compensate for the coverage 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: 'Add a card to the end of a platform set,' which an agent can act on. It does not, however, reconcile the name (add_screenshot) with the term 'card,' nor distinguish itself from siblings like copy_screenshot, duplicate_screenshot, or add_platform_set. Clear purpose, weak sibling differentiation.

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 implied by the behavior ('add a card to the end of a platform set'), but there is no explicit when-to-use, when-not, or named alternative despite a crowded sibling set of add_*, copy_screenshot, and duplicate_screenshot. The agent must infer routing rather than being told 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?

No annotations are provided, so the description carries the full burden. It discloses the mutation and that an editor must be open, but says nothing about required permissions, what happens when screenshotId is invalid, whether the new layer is returned/identified, or how TextShadow/borderGroup defaults behave.

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. It is efficiently written, though it underspecifies a 19-parameter tool rather than being richly structured.

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 annotations, no output schema, 19 parameters at 32% coverage, and no sibling disambiguation, the description is far too thin for the tool's complexity. An agent can tell what it does but not how to call it correctly or what to expect 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?

19 parameters with only 32% schema description coverage, and the description contributes zero parameter information. Several names are non-obvious in this domain (content, align, fontWeight, the eight textShadow*/border* fields) and are undocumented in both places, so the description fails to compensate for the coverage 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?

Names a specific verb (add) and resource (text layer) plus the target context (a screenshot in the open editor), which separates it from add_div, add_asset, and add_phone. It does not explicitly distinguish itself from update_text/remove_text, but the create-vs-modify distinction is implied by the verb.

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?

Only the implicit precondition 'in the open editor' is given. There is no guidance on when to call add_text versus update_text or remove_text, no mention of prerequisites such as the screenshot existing, and no exclusions.

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 burden and does so richly: it discloses cost (spends credits), scope of mutation (translates screenshot text and store listing), an exception rule (social screenshot text copied unchanged), a non-effect (does not switch the open language), and two failure modes (insufficient credits, existing code). This is exactly the behavioral context annotations would otherwise need to supply.

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 action is front-loaded, then each subsequent sentence adds a distinct behavioral fact (scope, exception, cost, non-effect, failures) with no filler. It is dense but every sentence earns its place; only minor tightening is possible.

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 single-parameter tool with no annotations and no output schema, the description is complete: it covers action, scope, side effects, cost, and failure conditions the agent needs to invoke it correctly. No meaningful gap remains.

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 schema already documents the languages array with limits (1-5) and example codes. The description only restates the 'up to 5 languages' cap, adding no syntax or format detail beyond what the schema provides, 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?

States a specific verb (add/translate up to 5 languages) and resource (the open language's iOS/Android screenshot text and store listing), and explicitly distinguishes itself from the set_language sibling by noting it 'Does not switch the open language'. An agent can route to it correctly without opening any 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?

Usage context is clear: use it to add languages via the AI localize flow, with caveats that it spends credits and fails if the account cannot spend or a code already exists. It implies but never explicitly names the alternative (set_language) for actually switching the open language, so it falls just short of full when/when-not guidance.

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 burden. It does disclose useful behavior: the output is a JPEG, the cards are rendered as the editor renders them, and the platform set defaults to the first one. It does not state whether the call is read-only, whether it needs auth, or how the image is returned, so it is partial rather than complete.

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, front-loaded with what is returned and followed by usage and default behavior. Nothing is padded, though the phrasing is slightly telegraphic.

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 capture tool with no annotations and no output schema, the description covers the return type and defaulting behavior but omits how the JPEG is delivered, whether the call is safe/read-only, and any prerequisites. Adequate but with clear 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?

The single platformSetId parameter has 0% schema description coverage, and the description only partially compensates by noting the default ("first platform set"). It adds real meaning about defaulting behavior but says nothing about accepted ID formats or how to discover valid values.

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 (return) and resource (one JPEG of every card in a platform set, side by side, as the editor renders them), which is concrete and unambiguous. It does not name the adjacent sibling get_editor_snapshot or otherwise distinguish itself from other capture/screenshot tools, 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?

"Use it to check your edits" gives a single implied use case, which is a genuine usage hint but no exclusions or alternatives. Nothing tells the agent when to prefer this over get_editor_snapshot or add_screenshot.

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 burden and falls short. It doesn't say whether the source screenshot is preserved, whether this creates a new screenshot entity, what permissions are needed, or what happens if the target platform set is invalid.

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 short sentence with no wasted words and the core action front-loaded. However, the brevity reflects under-specification rather than tight editing, so it is only minimally adequate.

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 mutation-style tool with zero annotation coverage, no output schema, and two fully undocumented parameters, the description is too thin. It should at least indicate source preservation, error behavior, or the relationship to the sibling copy/move/duplicate 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 0%, so neither screenshotId nor targetPlatformSetId is documented in the schema. The description only loosely implies them via 'a screenshot' and 'another platform set', adding no format, source-scope, or ID-resolution detail to compensate for the coverage 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?

States a specific verb ('Copy') and resource ('screenshot') plus the destination concept ('another platform set'), which maps cleanly to the two required parameters. It is reasonably distinguishable from duplicate_screenshot and move_screenshot, though it never explicitly contrasts itself with either.

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 when-to-use guidance, no prerequisites, and no distinction from the closely related siblings duplicate_screenshot, move_screenshot, or add_screenshot. An agent must guess whether 'copy' means duplicating in place, moving, or creating a new screenshot on a target platform set.

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 that the duplicate is inserted immediately after the original, which is a meaningful ordering side effect, but it does not cover permissions, new IDs, reversibility, or whether selection changes.

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 efficient sentence that is front-loaded with the verb and resource, with no filler or repetition. Every part of the sentence contributes to understanding the 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 simple duplicate operation with one required parameter, the description gives the core action and placement behavior, but it omits parameter detail and mutation side effects. With no annotations or output schema, it is minimally adequate rather than fully complete.

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 never mentions the single required screenshotId parameter. The parameter name is somewhat self-explanatory, but the description adds no meaning about its expected value or format beyond what the bare schema property already implies.

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 (duplicate) and resource (screenshot) plus the placement effect (insert copy immediately after it). It is clear what the tool does, but it does not explicitly distinguish itself from close siblings such as copy_screenshot or add_screenshot by naming alternatives.

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 guidance is given on when to use this tool versus alternatives like copy_screenshot, add_screenshot, or move_screenshot. The description only states what the tool does, leaving selection entirely 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 full burden and does well: it discloses a cost ('Spends credits'), a persistence side effect (saved to the account library), a scope exclusion (not placed on a card), and the return shape. It still omits auth/permission needs and any indication of latency or failure 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?

Three sentences, front-loaded with the core action and side effect, with cost and return details following logically. 'with a preview of each pose' partially restates 'poses like get_sprite,' a small redundancy.

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 correctly compensates by naming the return fields (imageUrl, poses, preview per pose). Cost, persistence, and the non-placement constraint are all covered, leaving only parameter detail and permission requirements unaddressed.

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 67%, so the schema already documents prompt and referenceUrl; the description adds no parameter-level meaning at all. The 'quality' enum (medium/high) has no description in either place, leaving its cost/quality tradeoff unexplained – hence the baseline 3 rather than a bonus.

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 ('Generate an asset sprite with AI') plus the persistence side effect ('save it to the account library'), which cleanly separates it from add_asset, update_asset, generate_background, and generate_mascot. An agent can identify the operation 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?

Provides an implicit when-not via 'Does not place it on a card,' which signals a boundary versus placement tools, and it references get_sprite for the output shape. However, it never states when to prefer this over add_asset or the other generate_* tools, so the routing 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?

With no annotations, the description carries the full behavioral burden, and it does disclose one genuinely useful non-schema trait: the operation consumes credits. It leaves everything else undisclosed — whether generation is synchronous, rate limits, or what happens to the existing background. Real but partial 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?

Two short, front-loaded sentences with zero filler, and the cost warning sits where a reader will see it. It is efficient, though the terseness edges toward under-specification for a credit-consuming generative tool.

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 annotations, no output schema, and 0% parameter coverage mean the description must do all the work, and it does not: no return-value shape, no prompt semantics, no failure/mutation behavior. Inadequate for a two-parameter generative 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% and neither parameter is clarified. 'one card' loosely implies screenshotId identifies the target, but the 'prompt' parameter — which governs the generated output — is never explained, leaving half the parameters undocumented in both schema and description.

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 (Generate) + resource (AI background) + scope ('one card'), which separates it from the project-level sibling set_project_background. It does not, however, distinguish it from the other generation siblings generate_asset and generate_mascot, so sibling differentiation is only partial.

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 generate_asset, generate_mascot, or set_project_background, and no prerequisites or exclusions. The only guidance is an implicit cost warning ('Spends credits'), which does not route the agent among alternatives.

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 burden and does real work: it discloses a credit spend, a persistent side effect (saved to the account library), the return shape (imageUrl plus poses with previews), and an explicit non-action (not placed on a card). It stops short of covering auth requirements, whether generation is reversible, or failure/latency 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?

Three short sentences with zero filler. The core capability, the cost, the return contract, and the scope limit are each front-loaded and distinct.

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 credit-spending generation mutation with no output schema and 50% parameter coverage, the description covers cost, persistence, and return shape but leaves the two undocumented parameters (quality, presetId) unexplained. It also outsources the return format to 'like get_sprite', forcing a cross-tool lookup.

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 only 50% — prompt and referenceUrl are documented in the schema, while quality and presetId expose only bare enums with no explanation of tradeoffs (e.g., credit cost of 'high'). The description mentions no parameter at all, so it adds no meaning beyond the schema and fails to compensate for the coverage 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?

States a specific verb and resource ('Generate a mascot sprite with AI and save it to the account library'), which separates it from generic generate_asset/generate_background siblings. It also clarifies downstream scope ('Does not place it on a card'). It never names the adjacent generation tools explicitly, so sibling differentiation is inferential rather than stated.

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 credit cost and the 'does not place it on a card' exclusion imply a usage boundary, but there is no explicit when-to-use guidance. Nothing tells the agent when to prefer this over generate_asset, or when to choose a presetId versus a free-form prompt.

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 present, the description carries the full burden and does well, disclosing the non-obvious two-step retrieval behavior: screenshotsOmitted is returned and screenshot bodies are withheld until a follow-up call. It doesn't state permission requirements or explicitly confirm the operation is side-effect-free, but the 'Read' framing and pagination disclosure are substantive.

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 compact sentences, front-loaded with the core action before the conditional branches. Every sentence contributes to the retrieval logic; no filler, though it is noticeably denser than typical definitions.

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, so the description must convey return behavior, and it does explain the set directory, screenshotsOmitted, and withheld screenshot bodies. Given only two optional parameters, this is close to complete for an agent to invoke 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%, so the schema already documents both parameters, including the enum values and their individual meanings. The description clarifies how the two parameters relate (either one includes that set's screenshots), adding marginal value, so 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 ('Read') and resource (one platform of the open editor), which clearly separates it from the mutation-heavy sibling set (add_*, remove_*, update_*, set_*). The scope is understandable, though 'Read one platform' is slightly misleading given that a multi-set project returns a directory rather than a platform.

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 explains the conditional behavior: no argument returns a single set, or a set directory when multiple sets exist, and instructs the agent to call again with 'platform' or an id from the directory. This is clear usage context, though it never names an alternative sibling 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?

With no annotations, the description must carry the behavioral load, and it does so unusually well: it discloses the return shape (same as a list_library item), names the notable nested fields (spriteSheet, poses), and reveals the non-obvious behavior of compositing one image per pose with its index drawn beside it. It omits read-only/permission context, but for a fetch tool this is solid.

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 return-shape information front-loaded and no filler. The second sentence adds genuinely useful detail rather than 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?

With no output schema and no annotations, the description does the necessary work of describing the return payload, including nested fields and image composition. It is incomplete on the input side, though, leaving imageId unexplained and giving no guidance on sourcing it from list_library.

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 the description never explains imageId — not its meaning, format, or how to obtain it. The only hint is the general notion of a 'saved asset or mascot,' which does not map clearly to the parameter name, so the description fails to compensate for the coverage 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?

States a specific verb (Return) and resource (one saved asset or mascot), and explicitly relates it to list_library, helping the agent distinguish a single fetch from the listing tool. It is slightly loose in calling the resource both 'asset' and 'mascot' without clarifying the relationship, but the intent is clear.

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: by contrast with list_library it reads as the singular lookup for one item, and the required imageId suggests fetching by identifier. However there is no explicit 'use this when' statement, no mention of where imageId comes from, and no exclusions.

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 burden and delivers real behavioral context: it discloses an unusual return artifact (one composite image of up to 10 items with each id beside its picture) and explains the spriteSheet/pose/crop-rectangle relationship. It still omits auth/account requirements and any rate or size limits beyond what the schema states.

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 front-loaded sentences with no filler, leading with the primary scope. The third sentence is telegraphic ('crop rectangles for add_asset spriteCoordinate') but earns its place by linking to a real workflow.

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 and no annotations, so the description must cover return shape itself, and it does hint at the image-plus-ids payload and pose metadata. It is complete enough for an agent to call correctly, though a fuller field listing would be better without an output schema.

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 67%: page and limit are documented in the schema, but kind is an undescribed enum. The description compensates by clarifying the asset vs mascot distinction, which is the only meaning that parameter needs. It adds value over the structured data for the one 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?

Names a specific verb and resource ('List assets or mascots saved on this account') and immediately scopes out what it is not ('not screenshots or backgrounds'), which is the key ambiguity against sibling tools like get_sprite. An agent can identify the tool's domain 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?

The negative scoping ('not screenshots or backgrounds') functions as an implicit when-not-to-use cue, and the mention of add_asset spriteCoordinate hints at a workflow pairing. However, no alternative tool is named for retrieving screenshots/backgrounds, so routing 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?

No annotations are provided, so the description carries the full burden. It discloses only the scoping constraint ('within its platform set') and says nothing about what happens at the boundaries (e.g. moving the first item left), whether the change is persisted immediately, or permission requirements. For a mutation tool with zero annotation coverage this is thin.

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 sentence, front-loaded with the verb and scope, with no filler. It is efficient, though its brevity reflects under-specification rather than disciplined trimming.

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 two-parameter mutation tool with no annotations, no output schema, and 0% schema description coverage, the description omits boundary behavior, ordering semantics, and success/failure outcomes. An agent can guess the basic call but not the edge cases.

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 restates the direction values ('left or right') already conveyed by the enum and implies a screenshot identifier, but adds no format, ID source, or ordering semantics for screenshotId. The added value over the schema is marginal.

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 (move), resource (screenshot), and scope (left/right within its platform set), which is enough to distinguish it from siblings like duplicate_screenshot or remove_screenshot. It does not, however, explicitly contrast with reorder_element, the nearest ambiguous alternative, so it stops 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?

There is no statement of when to use this versus reorder_element or update_screenshot, and no prerequisites are named. The phrase 'within its platform set' hints at a precondition (the screenshot must already belong to a set), but the agent must infer 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?

No annotations are provided, so the description carries the full burden. It discloses the frequency constraint ("once per task") and the rating scale, but says nothing about auth requirements, what the rating affects, or what the response looks like.

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, front-loaded sentences with zero waste. The core action and the frequency instruction are both stated immediately.

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 low-complexity tool with no output schema and no annotations, the description covers the basics but omits the comment parameter and any differentiation from report_mcp_feedback. It leaves meaningful gaps for correct invocation.

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 and 2 parameters, the description must compensate. It implies the stars value (1-5), matching the schema's min/max, but the optional comment parameter is entirely undocumented in both the schema and description.

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 (rate) and resource (these MCP tools) with a concrete scale (1 to 5 stars). It's clear what the tool does, but it doesn't distinguish itself from the sibling report_mcp_feedback, leaving an agent to guess which feedback channel applies.

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?

"for the task you just finished" and "Call it once per task" give clear timing and frequency context. However, it offers no exclusions or explicit comparison to report_mcp_feedback, so the boundary between the two feedback tools is unstated.

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 disclosure burden, yet it only says it reverts an undone edit. It omits the key behavioral facts an agent needs: whether it errors or no-ops when there is nothing to redo, whether it mutates editor state irreversibly, and whether it requires an open editor session.

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 core action and its target come first. 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 zero-parameter tool this is nearly sufficient, but with no annotations and no output schema, the description leaves unstated what the call returns and how it behaves on an empty redo stack. It is minimum viable rather than complete.

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 to document and the baseline of 4 applies. The description correctly implies the action targets the implicit 'open editor' rather than any specified argument.

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 ('Redo') and a specific object ('the last undone edit in the open editor'), which is unambiguous. The pairing with the sibling 'undo' is clear by convention, though the description never names it 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 implied rather than stated: 'the last undone edit' hints that an undone edit must exist, and the undo sibling is a natural alternative. There is no explicit when-to-use / when-not-to-use guidance or statement about what happens when the undo history is empty.

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 supplied, so the description carries the full behavioral burden, and it does not state whether the removal is reversible (is there an undo?), whether the underlying asset is deleted from the library or merely detached from the screenshot, or what permissions/state ('open editor') are required. Only the implicit mutation is conveyed.

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 redundancy. It is not padded, though it is arguably too terse given the 0% schema coverage it must compensate for.

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 annotations, no output schema, and no parameter documentation, the description leaves key questions unanswered: side effects on the asset library, undo/redo interaction, and error conditions when the asset or screenshot ID is invalid. For a destructive tool in a 48-sibling surface, this is under-specified.

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. The phrase 'an image layer from a screenshot' loosely maps assetId to the layer and screenshotId to the screenshot, but no ID format, source, or lookup tool (e.g., get_editor_snapshot/list_library) is mentioned, so the agent cannot reliably populate either field.

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+resource: 'Remove an image layer from a screenshot in the open editor' tells the agent exactly what is deleted and where it lives. It is reasonably separable from remove_text/remove_div/remove_phone by the 'image layer'/'asset' wording, but it never names a sibling or clarifies how it differs from remove_screenshot or update_asset.

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 when-to-use guidance, no prerequisites, no alternatives. The agent is not told whether this is the right call versus update_asset (e.g., to hide/replace instead of delete) or which removal tool applies to non-image layers.

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 implies a destructive mutation but says nothing about reversibility (siblings include undo/redo), permission requirements, failure modes for a bad divId/screenshotId, or side effects on other layers. This is a significant gap for a delete operation.

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, which is good structure. However, for a destructive two-parameter tool with zero structured documentation, the extreme brevity shades into under-specification rather than pure conciseness.

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 annotations, no output schema, 0% parameter coverage, and a large sibling set, the definition leaves essential questions unanswered: what happens to the removed layer, whether the action is undoable, and what the call returns. Adequate for identifying the tool, insufficient for calling it confidently.

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 largely does not. 'a box layer' and 'a screenshot' loosely correspond to divId and screenshotId, but no ID format, source, or constraint is given for either required parameter.

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 ('Remove a box layer') and scopes it to a screenshot in the open editor. This distinguishes it adequately from remove_asset, remove_text, remove_screenshot and remove_phone, though the 'box layer' wording only implicitly maps to the 'div' in the tool name.

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 no when-to-use guidance, no prerequisites (e.g., editor must be open, screenshot must exist), and never names an alternative such as update_div for modifying rather than deleting a layer. The phrase 'in the open editor' is the only contextual anchor.

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 hints at a constraint (only phones added via add_phone can be removed), but says nothing about permissions, reversibility, side effects on the screenshot layout, or failure modes for a destructive operation.

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 short, front-loaded sentence with no waste. Efficient, though its brevity is partly a symptom of under-specification rather than tight 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?

For a destructive two-required-parameter tool with no annotations, no output schema, and 0% schema coverage, the description leaves too much unspecified — no parameter meaning, no side effects, no failure behavior. Much more is needed at this complexity level.

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 never mentions phoneId or screenshotId. An agent gets no help on which screenshot the phone belongs to, ID format, or why both are required, leaving both parameters entirely 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 (Remove) and resource (phone), and differentiates from the sibling add_phone by naming it. It's clear what the tool does, though it doesn't distinguish itself from remove_asset/remove_div/remove_text beyond the resource noun.

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?

By tying the tool to 'an extra phone added with add_phone,' it implies the condition for use (undoing an add_phone call), which is real guidance. But there is no explicit when-to-use vs. alternatives, no exclusions, and no prerequisites.

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 discloses one behavioral constraint (the first set per platform is protected), but says nothing about whether deletion is permanent, whether the tool errors or silently no-ops when handed the primary set ID, or what the response looks like.

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, no filler, with the protection rule front-loaded right after the action. Sizing is appropriate for the tool's simplicity.

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 one-parameter tool with no annotations and no output schema, the definition should explain the failure mode (attempting to remove a primary set) and the severity of the deletion. Both are absent, leaving the agent to guess.

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 never mentions platformSetId — not where to obtain it, not whether it must reference a non-primary set, not its format. The single parameter is left entirely to the bare schema 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?

States a specific verb and resource ('Remove an ... platform set'), which is clearly distinguishable from the add_platform_set sibling by the remove/add contrast. The qualifier 'extra' is somewhat jargon-y and never defined, which keeps it from 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 second sentence, 'The first set of each platform stays,' is an implicit precondition: you cannot remove the primary set, only extras. That is real usage guidance, but it is stated as a rule rather than an instruction about when to reach for this tool versus add_platform_set or other remove_* siblings.

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. 'Remove' implies a destructive mutation, but the description says nothing about reversibility, whether an undo exists, error behavior for an unknown id, or whether the screenshot must be present in the editor.

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 short, front-loaded sentence with zero filler or repetition. It is efficient, though the brevity borders on under-specification for a destructive operation rather than being 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?

For a destructive, unannotated tool with no output schema, the description should at least explain the identifier and the effect on editor state. It leaves the agent without enough to invoke it confidently beyond guessing that screenshotId comes from elsewhere.

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 sole parameter screenshotId is a bare string with no description. The tool description never mentions the identifier, its format, or how to obtain it (e.g., from get_editor_snapshot), so it adds no meaning beyond 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?

States a specific verb (Remove) and resource (screenshot), scoped to 'the open editor', which distinguishes it from remove_asset/remove_div/remove_text by resource. It does not explicitly name a sibling or contrast itself with update_screenshot or duplicate_screenshot, so it is clear but not fully differentiated.

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 the other remove_* tools, no prerequisites (must the screenshot be selected/open?), and no mention of the undo/redo siblings that could reverse the action. The agent gets a purpose but no routing or context.

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 burden. 'Remove' implies a destructive mutation, but it does not say whether the deletion is reversible (an undo sibling exists), what happens if textId is not found, or whether permissions are required. Only the target scope is 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?

A single front-loaded sentence with zero filler; the verb and target are established immediately.

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 two-parameter, no-output-schema removal tool this is close to minimally adequate, but with no annotations and no parameter documentation the agent is left guessing about reversibility and error behavior. A brief note on undo/irreversibility would close the 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 description coverage is 0%, so the schema documents nothing. The description only implies that screenshotId identifies the screenshot and textId the text layer; it adds no format, ID-source, or lookup guidance to compensate for the coverage 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?

States a specific verb (remove), resource (text layer), and scope (from a screenshot in the open editor), which distinguishes it from remove_screenshot, remove_asset, and remove_div. It stops short of naming update_text as the modification alternative, but the resource target 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?

No when-to-use or when-not-to-use guidance. The agent must infer that this deletes a text layer rather than editing it (update_text) or removing the whole screenshot (remove_screenshot), and there is no mention of prerequisites such as the editor needing to be open on that screenshot.

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 and does very little. 'The open project' hints that the target is implicit rather than addressable, but it says nothing about whether the rename is reversible, what happens if the name is invalid or duplicate, or whether the change must be saved or is persisted immediately.

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, which is structurally clean. However, the brevity is under-specification rather than true conciseness given a mutation with an undocumented parameter.

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 annotations, no output schema, and a 0%-documented parameter, the description should explain what is mutated and how the new name is supplied. It leaves the agent without the information needed to invoke the tool confidently.

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 the single 'name' parameter. The description never clarifies that 'name' is the new project name, nor does it state constraints on it (length, uniqueness, allowed characters), so the parameter remains semantically undocumented in both schema and description.

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 ('Rename') and resource ('the open project'), so an agent knows exactly what the tool does. It does not differentiate itself from any sibling, but no sibling overlaps with project renaming, so ambiguity is low.

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 'the open project' implies it acts on the currently active project, but there is no explicit statement of when to use this tool versus alternatives, no prerequisites, and no error/edge conditions.

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 burden and does so well: it discloses the one-step granularity, the same-kind restriction, and the full back-to-front paint order (divs, phones, image layers, front divs, texts). It omits edge behavior at the extremes and whether the action is undoable.

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 sentences, front-loaded with the core action before the constraint detail. The paint-order clause is dense and slightly awkward to parse, but nothing here is padding and the size suits the 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?

For a 4-parameter mutation tool with no annotations and no output schema, the description covers operation semantics but leaves parameter roles and failure/return behavior unaddressed. Adequate but with clear 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 0%, so the description must compensate. It clarifies that 'kind' refers to layer kinds and 'direction' is a single forward/backward step, but it never mentions elementId or screenshotId, leaving half the parameters explained only by their enum values or 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 gives a specific verb (move) and resource (a layer), plus the exact scope: 'one step forward or backward among layers of the same kind.' This clearly distinguishes the operation from add/update/remove siblings, though it never names an alternative tool to route between.

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 implied rather than stated — an agent infers this is for z-order adjustment. The constraint 'cannot move a layer across kinds' is a useful guardrail, but there is no explicit when-to-use framing or comparison to a sibling like move_screenshot.

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, and it discloses almost nothing beyond what and when. It does not say where the feedback goes, whether it is anonymous, whether it requires consent, whether the call mutates anything, or what a success response looks like.

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 well-formed sentence with the action front-loaded and no filler; the trailing "when you notice one" is slightly loose but adds the trigger condition rather than 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?

For a three-parameter submission tool with no annotations and no output schema, the description omits how to compose the message, the scope/semantics of toolName, and what happens after reporting. It is not complete enough to call confidently without opening the schema.

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 effectively enumerates the 'kind' values (bug, unexpected result, suggestion) and implies 'toolName' ("about these MCP tools"), but the required 'message' parameter is never explained, nor is toolName indicated as optional.

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 concrete verb (report) and resource (bug/unexpected result/suggestion about these MCP tools), which is distinguishable from the design-editor siblings like add_div or generate_asset. It does not explicitly differentiate from the closely related rate_this_mcp sibling, which is the main gap.

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?

"when you notice one" gives a trigger condition for when to use it, which is better than nothing. But it offers no guidance on routing between this and rate_this_mcp (a near-neighbor sibling), and no exclusions or prerequisites.

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 doesn't state that this is a read-only operation, whether auth is needed, rate limits, or what the results contain. The only behavioral hint is the meaning of the 'usable' field, which is partial.

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, front-loaded with the core action. The second sentence covers the 'usable' field, which is useful, though its placement slightly interrupts the flow.

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 annotations and no output schema, the description should describe the operation's safety profile and return structure. It only partly covers the 'usable' field and leaves the result format and behavioral traits undocumented, so it falls short for a search 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 67%, so the schema documents most parameters. The description echoes the query concept ('part of a family name') and category concept without adding syntax or format detail beyond the schema, matching a baseline 3.

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 (Search) and resource (Google Fonts) plus the searchable dimensions (family name, category). It references the sibling add_project_font, giving partial differentiation, though it doesn't fully contrast itself against related font tools.

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?

It explains how to search (by name, category, or both) but gives no explicit when-to-use guidance, prerequisites, or conditions distinguishing it from add_project_font or list_library. Usage is left entirely 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 full burden and does disclose meaningful behavior: borderless-frame renders the screenshot without a phone frame, MacBooks are HyperRealistic-3D-only and fill the display (16:10 loses a sliver), and the lid responds to foldAmount. It omits error/failure behavior and permission requirements, but the visual-consequence disclosure is genuinely useful.

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 purpose is front-loaded, but the body is a dense run-on that re-lists every enum value already present in the schema. The grouping-by-platform adds value, yet the flat single-paragraph enumeration of ~21 IDs is verbose where structure or reliance on the schema enum would be tighter.

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 two-param setter with no annotations and no output schema, the description covers the consequential choice (deviceId) and its visual/platform constraints well. The unexplained platformSetId and absence of any error or return behavior keep it from fully complete.

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%, so the description must compensate—and it does for deviceId by grouping valid values per platform type and explaining the visual effect of borderless-frame and MacBook devices. platformSetId is never explained, leaving that half of the parameters undocumented in both schema and description.

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: 'Set the device of a platform set.' An agent can tell this apart from sibling setters like set_realistic_frame or set_squircle_frame, though the description never names those alternatives explicitly to sharpen the boundary.

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?

It provides conditional rules about which deviceIds a given platform set accepts (iOS/Android/Social), which implicitly guides correct use, but it never states when to call this tool versus a sibling like set_realistic_frame, nor any prerequisite that the platform set must already exist.

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, and it is thin. It does not say whether the change persists in the project, whether it affects only the open editor or all editors, whether it is reversible via undo, or what happens if the language does not exist on the project despite the stated precondition.

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 clean sentence with the core action front-loaded and the constraint trailing it. No filler, no restatement of the tool name.

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 mutation tool with no annotations, no output schema, and an undocumented parameter, the description leaves too much unstated: no failure behavior when the language is absent, no persistence or scope semantics, and no value format. It is a viable minimum but has clear 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 0% for the single required 'lang' parameter, so the description must compensate. It adds the constraint that the value must be a language already present on the project, which narrows the domain, but it never states the expected format (locale code such as 'en', display name, or ID), leaving the agent to guess the identifier shape.

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 pair ('Switch the open editor to a language'), scoped to the currently open editor, which is more precise than a bare 'set language'. It does not explicitly differentiate itself from the set_* siblings (set_device, set_resolution, set_template), but each targets a distinct setting, so an agent can place it easily.

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 'that already exists on the project' implies a precondition and a when-not condition (this tool will not create a new language), which is useful. However, no alternative tool or fallback path is named for the case where the desired language does not exist, so usage is only implied rather than spelled out.

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

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 signals bidirectionality ('link or unlink') but says nothing about scope of effect (all platform sets? current one?), idempotency, reversibility, or whether unlink destroys existing per-set overrides.

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 efficient sentence with the operation front-loaded. It is brief rather than bloated; the gap is under-specification, not verbosity.

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 mutation-style toggle with no annotations, no output schema, and an undocumented boolean, the description should clarify effect scope and parameter polarity. As written, an agent cannot reliably predict what enabling or disabling does.

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?

One parameter ('enabled') with 0% schema description coverage, and the description never maps true/false to link vs unlink. The reader must guess the polarity, which is a critical ambiguity for a boolean toggle.

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 pair (link/unlink) and resource (matching text layers across platform sets), which is a uniquely identifiable operation among the siblings — none of add_text, update_text, or remove_text perform linking. What 'link' means semantically is left implicit, but the operation is distinguishable.

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 indication of when to use this versus update_text or add_text, no prerequisites, and no guidance on which direction (link vs unlink) a given call performs. The agent must infer everything from context.

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 does disclose a genuinely useful trait: on HyperRealistic sets the device only shows real finishes and generic colors snap to the closest finish. However it says nothing about permissions, persistence, or what the operation returns, leaving meaningful gaps for a mutation tool.

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

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

Two sentences, front-loaded with the core action and followed by the conditional nuance. The second sentence is dense but every clause (threeDFrame condition, id source, color list, snapping behavior) 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?

The tool is a simple two-parameter mutation with no annotations and no output schema, and the description covers the key behavioral nuance well. It still omits any mention of side effects, persistence, or the role of platformSetId, leaving it adequate but not fully complete.

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 only 50%, so the description must compensate, and it does: it explains that 'color' accepts either a deviceColors id (pointing to the snapshot as the source) or a generic color name, and clarifies the semantic consequence of each choice. The undocumented platformSetId is only weakly implied, keeping this short of a 5.

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 combination ('Set the device color of a platform set'), which is clearly distinct from siblings like set_device, set_resolution, or update_template_color. It does not explicitly name a sibling to disambiguate, but the resource is unambiguous enough that an agent can select it without opening schemas.

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 value-level guidance (use deviceColors ids on HyperRealistic sets, generic colors otherwise) but never states when to use this tool versus alternatives like set_device or set_realistic_frame. Usage is implied through the behavioral note rather than through explicit when/when-not 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 no annotations, the description carries the full behavioral burden. It discloses one non-obvious rule (empty string clears the background), which is real value, but says nothing about whether clearing is reversible, whether it requires permissions, what happens to the existing blur value, or what the call returns for a mutation tool.

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

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

Two short sentences with zero filler; the core action is front-loaded and the clearing rule follows immediately. Every sentence 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 low-complexity two-parameter mutation with no output schema, the description covers the primary path adequately. It is incomplete on the blur parameter's meaning and on the consequences of clearing, which an agent would need to call the tool confidently.

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 does explain the sentinel semantics of imageUrl (empty value = clear), which the schema cannot convey, but it says nothing about blur, whose 0-3 enum values are left entirely unexplained beyond the schema's raw enum list.

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 pair (set/clear) and a specific resource (the project background image), so the agent knows exactly what the tool mutates. It does not, however, distinguish itself from the related sibling generate_background, which is the main risk of mis-selection in this toolset.

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 actionable usage guidance for the clear case ("Pass an empty imageUrl to clear it"), which is genuinely helpful. It offers no guidance on when to use this tool rather than generate_background, add_asset, or upload_image, so selection among siblings 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?

With no annotations, the description carries the full burden. It usefully discloses that threeD selects a HyperRealistic 3D model and that borderless frames are excluded, which is genuine behavioral context, but says nothing about permissions, reversibility, or side effects on existing frames/screenshots.

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 tightly written sentences with the core action front-loaded and no filler. The trailing restriction sentence is worth its space, though the phantom rotation parameters add noise.

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 no-annotation mutation tool with an output-less schema and two undocumented parameters, the description covers only the threeD axis. It omits the semantics of enabled/platformSetId and any safety or return-behavior context, and introduces parameters that aren't callable.

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 only 33% (only threeD is documented), so the description should compensate for enabled and platformSetId, which it does not. Worse, it references rotationX, rotationY, and rotationZ parameters that do not exist in the schema, which can mislead an agent about the call shape.

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 (enable/disable) and resource (realistic device frame on a platform set), which is enough to separate it from frame-adjacent siblings like set_squircle_frame and set_show_notch. It stops short of naming those alternatives explicitly, so it earns a 4 rather than 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?

Usage is implied by the enabling/disabling framing and one real constraint is given ('3D works on every device except borderless-frame and android-borderless-frame'). However there is no guidance on when to pick this over set_squircle_frame/set_show_notch or what state the platform set must be in.

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 of behavioral disclosure, and it says nothing about permissions, whether the platform set must already exist, how existing content reacts to a resize, or reversibility. "Set" implies mutation but nothing about its consequences is stated.

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 short sentence that is front-loaded and waste-free, but it is terse to the point of under-specification rather than genuinely efficient. Nothing is padded, yet nothing earns extra credit.

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?

A three-parameter mutation tool with no annotations, no output schema, and zero schema descriptions needs far more from the description than one sentence. An agent cannot verify units, id format, or side effects before invoking it.

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 none of the three parameters are documented. The phrase "pixel size" loosely maps to width/height, but platformSetId is entirely unexplained (is it an id from add_platform_set? a slug?), so the description does little to compensate.

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 (set) plus the resource and attribute (pixel size of a platform set), which is clearer than the many generic set_*/update_* siblings. It does not explicitly differentiate itself from neighbors like set_device or update_phone, but the resource+property 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?

No when-to-use guidance, no prerequisites, and no mention of alternatives among the large family of set_* tools. The agent gets no signal about when this is the right call versus add_platform_set or remove_platform_set.

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 burden. 'Show or hide' implies a reversible state toggle but says nothing about whether the change persists, what permissions are needed, or whether hiding the notch affects other frame/border settings.

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 short sentence with no filler, and the action is front-loaded ahead of the target. Efficient, though it is arguably too terse rather than wasteful.

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?

A 2-parameter mutation tool with no annotations, no output schema, and 0% schema description coverage receives very little compensating detail. An agent lacks the identifier semantics and behavioral context needed to invoke it confidently.

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 but only partially does: 'show or hide' maps to the boolean `show`, but platformSetId is never explained (identifier format, where to obtain it). Half the parameters remain undocumented.

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 pair ('show or hide') and a specific resource ('the notch on a platform set'), so an agent knows exactly what the tool manipulates. It does not, however, differentiate itself from adjacent appearance tools like set_realistic_frame or set_squircle_frame, which is why it stops 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?

There is no guidance on when to use this versus the other 'set_' appearance tools or any prerequisite (e.g. that the platform set must already exist). Usage is only inferable from the name.

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 does not say whether toggling this frame affects other frame settings, whether it persists across sessions, or whether any permission is required, leaving the mutation's side effects 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?

A single compact sentence with the action and target front-loaded. It is efficient, though it is arguably too terse for the disclosure gaps it leaves.

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 two-parameter boolean toggle with no output schema and no nested objects, the description is minimally viable. It omits any behavioral or usage context that would matter for an agent deciding when and how to flip this frame.

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. The word 'enable or disable' loosely maps to the boolean 'enabled' param, but 'platformSetId' is never explained and no format or identifier expectations are given.

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 pair (enable/disable) and resource (squircle frame) scoped to a platform set. An agent can distinguish it from the adjacent set_realistic_frame sibling, though the description never names that sibling explicitly.

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

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

Provides no guidance on when to enable vs disable, no prerequisites, and does not mention set_realistic_frame or any other alternative framing tool. The agent must infer usage entirely from the name.

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 implies mutation but never says whether setting a template overwrites prior template settings, whether it is reversible, or whether it requires an open/active project context. 'Of the open project' hints at a precondition but is not elaborated.

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 short sentence with no filler, appropriately sized for a one-parameter tool. It is front-loaded, though the brevity edges into under-specification rather than efficient concision.

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 mutation tool with no annotations and no output schema, the description is too thin: it omits what gets changed, whether prior settings are replaced, any preconditions, and any effect on existing project styling. An agent would be guessing about side effects.

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 says nothing about templateId. The schema's enum lists the six valid values, so the value domain is known, but the description adds no meaning about what each template does or how the choice affects the project.

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 clear verb ('Set') and resource ('template') scoped to 'the open project', so the agent knows the general operation. However, it doesn't clarify what a 'template' means here (visual theme vs. structural template) or distinguish this from the sibling update_template_color.

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 guidance on when to use this tool, no prerequisites (e.g., does a project need to be open, does this overwrite existing customization?), and no named alternatives among the many sibling tools.

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 implies single-step reversal ('the last edit') but does not say whether repeated calls step further back through history, whether the operation fails silently or errors when the stack is empty, or what the response looks like.

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 wasted words; the action and its scope are stated immediately.

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 trivial no-parameter tool this is close to adequate, but a mutation-flavored action with no annotations and no output schema should at least indicate the empty-stack behavior or that a 'redo' sibling exists to reverse it.

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 explain beyond what the empty schema already shows. Baseline for a no-parameter tool.

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 ('Undo') and resource ('the last edit in the open editor'), making the effect unambiguous. It does not, however, distinguish itself from the sibling 'redo', which is the one tool an agent most needs to disambiguate against.

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 guidance on when to use this versus 'redo', and no note about preconditions such as whether an undo stack exists or what happens when there is nothing to undo. Usage is only implied by the tool name.

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 supplied, so the description carries the full behavioral burden and delivers very little. It does not say whether unspecified fields are left untouched or cleared, whether the change is undoable, whether the editor must already contain the asset, or what a failure looks like. 'In the open editor' is the one useful disclosure about required state.

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 redundancy. It is efficiently structured, though for an 8-parameter mutation tool the terseness borders on under-specification rather than serving brevity.

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-parameter write tool with no annotations, no output schema, and only 50% schema description coverage, the description leaves most of what an agent needs unaddressed: update semantics, partial-vs-full replacement, and half the parameter meanings. Only the basic purpose and the editor-state hint are 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 coverage is exactly 50%: x, y, width, and height are documented in the schema, but src, rotation, assetId, and screenshotId are not. The description adds no parameter meaning at all, so the under-documented half of the parameters is unexplained in both places. With low coverage the description is expected to compensate 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?

States a specific verb (Update) and resource (an image layer on a screenshot), which is enough to distinguish it from update_div, update_text, and update_phone. It does not, however, explain how it relates to the near-sibling add_asset/remove_asset or why the name says 'asset' while the description says 'image layer'.

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 when-to-use guidance, no prerequisites, and no mention of alternatives such as add_asset (for new layers) or update_screenshot (for whole-screenshot changes). The only contextual clue is the phrase 'in the open editor', which hints at a required editor state but does not spell it out.

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 and discloses almost nothing. It does not state whether this is a partial or full update, whether omitted fields are preserved, that an empty html string clears the card, or that the operation can be undone. Only the verb 'Update' hints at mutation.

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 six-word sentence is front-loaded and free of padding, so there is no structural waste. However, it is under-specified rather than concise: for a 15-parameter mutation tool, this brevity leaves the agent with nothing beyond the 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?

For a 15-parameter mutation with no annotations and no output schema, one sentence is not enough. The agent cannot tell what gets mutated, what happens to unspecified fields, or how the layer relates to other elements, even though the schema partially covers the parameter space.

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 adds no parameter meaning whatsoever; all parameter documentation lives in the schema. Coverage is 67%, leaving divId, screenshotId, opacity, borderRadius, and backgroundColor with no explanation in either place, and the description does nothing to compensate for that 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?

States a specific verb (update) and resource (box layer / div), and clarifies what a 'div' actually is by calling it a 'box layer on a card'. It is distinguishable from add_div and remove_div by the verb, but it offers no differentiation against the many other update_* siblings such as update_text, update_phone, or update_asset.

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 statement of prerequisites (e.g. an existing divId), and no pointer to alternatives like add_div or remove_div. The agent must infer that this mutates an existing layer rather than creating one.

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 and is a mutation tool, yet it says nothing about permissions, partial-update semantics (are omitted fields left unchanged?), reversibility, or side effects on the render. It only implies a precondition (phone must already exist), which is minimal disclosure for a 37-param write operation.

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, purpose front-loaded, no filler. The middle pointer sentence and the closing routing sentence both do work, though the reference to update_screenshot is repeated in effect.

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?

A 37-parameter mutation tool with no annotations and no output schema needs far more coverage than this provides; most of the parameter surface and all behavioral semantics are unaddressed. The cross-reference to update_screenshot is the only attempt to bridge the 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 description coverage is only 35% across 37 parameters, so the description must compensate and largely does not. "Takes the same phone fields as update_screenshot" is a useful pointer, but it offloads meaning to another tool an agent may not have loaded and leaves most parameters (shadows, focus overlay, fades) undocumented.

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?

"Update an extra phone added with add_phone" names a specific verb (update) and resource (phone), and the third sentence distinguishes it from update_screenshot by scope (extra phone vs main phone). This differentiates it from siblings like remove_phone and set_phone_color 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?

It explicitly states the object must have been created via add_phone and routes main-phone edits to update_screenshot, giving a clear when-to-use and a named alternative. It stops short of any exclusion or condition beyond that single routing rule, so it is not a full 5.

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. For a 43-parameter mutation tool it says nothing about permission requirements, whether omitted fields are left untouched (partial update semantics), reversibility (undo is a sibling), or what is returned. Only the imageUrl/device routing is 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?

Three sentences, front-loaded with the scope and then the cross-tool dependencies; no filler. It is impressively compact for a 43-parameter tool, though the field-category list is dense enough to read as a run-on.

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 43 parameters, no annotations, and no output schema, the description covers only the headline categories and two integration points. It leaves the agent without guidance on partial-update behavior, defaults, or the many undocumented visual parameters, which is not enough for a mutation tool of this size.

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 only 30% across 43 parameters, so the description must compensate and it only partially does: it groups the sprawl into categories and clarifies imageUrl (the app screen inside the phone, populated via upload_image) and deviceId's relationship to set_device. Dozens of color, shadow, focus-overlay, and pattern parameters remain unexplained in both schema and description.

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 ('Update a card and its main phone') and enumerates the categories of changeable state: background, phone placement and app screen, pattern, fade, shadow. It does not explicitly distinguish itself from the close sibling update_phone, so an agent must infer the boundary.

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?

Provides helpful workflow routing for two fields: imageUrl must come from upload_image with type screenshot, and the phone model follows set_device. However, it never says when to call update_screenshot versus update_phone, add_screenshot, or duplicate_screenshot, and gives no exclusions or prerequisites.

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 burden. It usefully discloses a scope limitation (no copy generation) and the return shape (names of fields written), but says nothing about permissions, whether partial updates are allowed, whether existing values are overwritten, or what happens with an empty payload — significant gaps for a mutation tool.

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

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

Three short sentences, front-loaded with the action, and each sentence carries a distinct fact (scope, limitation, return value). No 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?

For a mutation tool with no annotations, no output schema, and nested-object parameters at 0% schema coverage, the description is too thin. An agent still cannot tell which fields are writable or what the expected payload shape is.

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 nested objects with no property documentation. The description only implies that appStore maps to the App Store listing and googlePlay to the Play listing; the actual writable field names inside those objects are undocumented in both schema and description.

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 (Update) and resource (App Store/Google Play listing fields), scoped to the current language, which separates it from sibling tools like update_text or update_screenshot. It does not explicitly name an alternative sibling, so it stops 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?

Implies the listing must be scoped to a language already set (likely via set_language) and rules out copy generation, hinting that copy work belongs to ai_translate. However, it never states prerequisites or explicitly names when to prefer another tool, 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?

No annotations are provided, so the description carries the full behavioral burden. It implies a mutation ('Update one color') but says nothing about permissions required, whether changes are reversible or persistent, or what happens on invalid input. The value constraints are useful but do not cover behavioral traits.

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-loading the purpose and then immediately providing the parameter constraints. Every phrase earns its place, with no redundant or vague language.

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 two-parameter mutation with no output schema and no annotations, the description supplies the necessary parameter context: valid colorId values per template and the CSS color format. It does not cover behavioral aspects like permissions or reversibility, but those are addressed in the behavioral transparency dimension. Given the complexity, the description is nearly complete.

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 so substantially by enumerating valid colorId values for each template type (e.g., 'minimal (bg), gradient (from, via, to)') and defining value as a CSS color like '#22c55e'. This adds significant meaning beyond the bare string types in the schema. It stops short of explaining how to determine which template is currently open, but the parameter semantics are otherwise rich.

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: 'Update one color of the open project's template.' This clearly distinguishes the action from siblings like set_template or set_project_background, which affect other aspects. However, it does not explicitly contrast with those siblings to help an agent choose between them.

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 important constraints on valid colorId values per template type and the CSS format for value, which implies usage. It does not state when to use this tool versus alternatives such as set_template or set_project_background, nor does it provide any exclusions or prerequisites.

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, yet it only says 'Update.' It does not disclose whether omitted optional fields are preserved or reset, whether the change is reversible/undoable, what editor state or permissions are required, or what is returned.

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, front-loaded sentence with zero waste. However, for a 20-parameter mutation tool the brevity leaves it under-specified rather than genuinely concise.

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?

Given 20 parameters, no annotations, no output schema, and 30% schema coverage, the description is far too thin. It omits partial-update semantics, editor-state prerequisites, and any return/effect information an agent needs to invoke 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 description coverage is only 30%, so the schema leaves most of the 20 parameters undocumented. The description supplies no parameter meaning at all, failing to compensate for the coverage gap (e.g., align, content, rotation, fontWeight, borderColor are defined nowhere).

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: 'Update a text layer on a screenshot in the open editor.' This distinguishes it from sibling update_div and update_asset, which target other element types. It is clear what it does, though it does not explicitly contrast with add_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?

No explicit when-to-use guidance or named alternatives. The agent must infer that this modifies existing text layers while add_text creates them, and that the editor must be open. No conditions or exclusions are 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?

With no annotations, the description carries the full burden and delivers: it discloses the one-time uploadUrl, the multipart field name "file," the response shape (JSON url), the single-use link constraint, and the retry path ("if the POST fails, call this tool again"). This is unusually complete behavioral disclosure for a mutation/upload tool.

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, followed by the mechanics, then consumers, then edge cases and fallback. Every sentence carries distinct operational information with no filler or repetition.

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 annotations and no output schema, the description still fully explains the two-step upload contract, the return value, downstream usage, and failure handling. Nothing an agent needs to call it correctly 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?

Schema coverage is 67% and the description adds real meaning beyond it: it clarifies base64 as a fallback rather than the default path, and ties type=asset to card images. The filename constraints and enum values are largely left to the schema, so it stops short of full compensation but adds genuine value.

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 ("Prepare an image upload") scoped to "the open project," and its two-step prepare/POST nature clearly separates it from sibling generators like generate_asset and direct mutators like add_asset. An agent can identify the tool's role 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?

Explicitly names the downstream consumers (update_screenshot imageUrl, add_asset src, set_project_background, add_div/update_div html), states the type=asset case for card images, and gives a clear condition for base64 ("only when you cannot make that HTTP request"). It routes the agent through the workflow rather than 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.