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

The description discloses nested children support, relative coordinate behavior, and the return structure {success, nodeIds, count, errors}. It also reveals that elements support any depth and that x/y are relative to parent frames. Since no annotations are provided, this is substantial disclosure of 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 long but well-organized with clear sections, code examples, and recipes. It front-loads the primary purpose and key capability, then details properties systematically. While lengthy, every section provides actionable information for an agent to construct valid batch_create calls.

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 the high complexity of the tool (multiple element types, nested children, many optional properties), the description covers all necessary dimensions: supported types, properties, recipes, and return format. With no output schema, it explains what the tool returns. The inclusion of 'errors' in the return value also anticipates failure 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?

The schema only defines 'elements' as an array of objects with no property descriptions (0% coverage). The tool description compensates extensively by documenting all supported element types (frame, rectangle, ellipse, vector, text, line), their properties, and providing multiple copy-paste recipes with concrete JSON examples.

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 opens with 'Create MULTIPLE Figma elements in a SINGLE round-trip' and declares it 'THE PRIMARY TOOL — use it for ALL designs,' clearly specifying the verb+resource and distinguishing it from sibling single-element creation 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?

Explicitly states 'THIS IS THE PRIMARY TOOL — use it for ALL designs,' providing clear when-to-use guidance. It also describes the screenshot→Figma workflow, indicating the intended use case, and differentiates from sibling tools by emphasizing multi-element creation and nesting.

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 provided, the description must carry the full burden of disclosing behavioral traits. It states the action (remove all elements) and scope (current page), but fails to mention irreversibility, potential data loss, or any warnings. For a destructive tool, this is a significant gap; an agent would not know to warn the user that the operation is permanent.

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

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

The description is a single sentence that front-loads the action ('Remove ALL elements') and adds a helpful parenthetical ('clean slate'). There is no redundancy or filler; every word earns its place.

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

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

The tool is simple (no parameters, no output schema), but it is a destructive operation. The description specifies the scope ('current Figma page') but omits critical operational details like irreversibility or whether confirmation is required. Given the lack of annotations, the description is minimally viable but not complete for safe 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?

The input schema has zero parameters, so the description adds no parameter-level meaning beyond the schema. With 0 parameters, the baseline is 4 because there is nothing to clarify. The description correctly focuses on the tool's effect rather than parameter details.

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

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

The description clearly identifies the action ('Remove ALL elements') and the scope ('from the current Figma page'). It distinguishes itself from the sibling creation tools (create_line, create_frame, etc.) by being the only tool that deletes content, making its purpose unmistakable.

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

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

The phrase 'clean slate' gives clear context for when to use the tool—when the agent needs to clear the entire page. There are no explicit exclusions or alternatives, but the sibling tools are all creation-focused, making this tool's role distinct. It lacks an explicit 'use this when' statement, but the usage is strongly implied.

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 explains angle conventions (0=top, clockwise) and arcInnerRadius semantics, which is useful. However, it does not disclose return behavior, side effects, or interactions with existing canvas elements, leaving gaps for a creation 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?

The description is well-structured, with the main purpose front-loaded followed by arc parameter details and a concrete recipe. The recipe is useful but slightly verbose, and the decorative line could be trimmed. Overall, it earns its place without excessive bloat.

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 17 parameters, no output schema, and no annotations, the description is far from complete. It covers only a subset of parameters and lacks information on return values, canvas behavior, or prerequisites. The recipe adds practical value but does not fill the gaps 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 coverage is 0%, so the description must compensate for 17 parameters. It only explains arcStartAngle, arcEndAngle, arcInnerRadius, and implicitly width/height. Many parameters like shadow, gradient, fillOpacity, and strokeOpacity remain undefined, which is insufficient given the low schema coverage.

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

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

The description clearly states 'Create a circle or ellipse' with a specific note that equal width/height produces a perfect circle. This distinguishes it from sibling tools like create_rectangle and create_line, and the mention of arc/donut support adds further specificity.

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

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

The description implies usage for circles/ellipses and provides a detailed recipe for multi-color donut rings, but it does not explicitly state when to use this tool versus alternatives like create_rectangle or when not to use it. The recipe is a concrete example, but no exclusions or alternative comparisons are given.

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 provided, the description must disclose behavioral traits, but it mostly lists parameters. It does not mention side effects, insertion behavior, selection context, z-order, or return values. The only behavioral tip is the glass-pane opacity guidance, which is useful but insufficient for full transparency.

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 front-loaded with a clear one-sentence purpose, followed by a compact parameter list. Each line is terse and informative, but the list is long due to 16 parameters. No filler or redundant explanation exists, though the 'basics' group could be more explicit.

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

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

The tool has 16 parameters, no annotations, and no output schema, so the description must provide broader context. While parameter semantics are rich, the description omits critical contextual information such as where the frame is created, whether it becomes the active container, how children attach, and what the tool returns. This is a significant gap for a complex creation tool.

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

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

The schema has 0% description coverage, so the description carries the full burden for parameters. It covers 14 of 16 parameters with meaningful details: hexColor format, fillOpacity range with a practical tip, gradient structure with angle/stops, shadow fields, and blur definition. It misses opacity and clipsContent, preventing a perfect score.

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 opening line 'Create a Figma Frame (artboard/container)' states a specific verb and target resource, clearly distinguishing frames from sibling tools like create_rectangle, create_ellipse, and create_text. The parenthetical '(artboard/container)' further clarifies the intended role of a frame.

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

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

The description implies usage as an artboard or container, but it does not explicitly state when to prefer create_frame over siblings such as create_rectangle or batch_create. No alternative tools are named, and there are no when-to-use or when-not-to-use instructions.

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 of behavioral disclosure, but it only states the creation action. It does not mention side effects, canvas interaction, or any non-obvious behavior like whether it adds a new element or modifies existing ones.

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

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

The description is a single sentence and is concise, but it is too under-specified to be considered appropriately sized for an 8-parameter tool. It earns its place for purpose clarity but omits essential guidance.

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 the tool's complexity (8 optional parameters, no annotations, no output schema), the description is severely incomplete. It provides no context about defaults, rendering, or how the line appears, making it insufficient for an agent to use 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?

All 8 parameters have no schema descriptions (0% coverage), and the description does not compensate by explaining any parameter meanings or relationships. The word 'horizontal' implies the line's orientation but gives no insight into x, y, width, stroke, etc.

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

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

The description clearly states the tool's function with a specific verb ('Create') and resource ('horizontal divider line'), which differentiates it from sibling tools like create_rectangle or create_text. It conveys the exact purpose without ambiguity.

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 usage guidance is provided—the description does not indicate when to use this tool versus alternatives, nor does it mention any prerequisites or context. A clear gap for a creation tool among many sibling creation 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?

No annotations are provided, so the description must disclose behavior. It only mentions creation and styling; it does not address side effects, return values, canvas requirements, or reversibility. The glassmorphism recipe is a style hint rather than a behavioral disclosure.

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 plus a compact recipe block, with no redundant content. It is front-loaded with the purpose and provides a structured example.

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 18 parameters and no output schema or annotations, the description covers only the glassmorphism scenario. It lacks information about other styling options, return values, or behavior beyond creation, making it incomplete 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?

The input schema has 18 parameters with 0% coverage from the description. However, the glassmorphism recipe provides concrete values for 8 parameters (hexColor, fillOpacity, cornerRadius, stroke, strokeOpacity, strokeWidth, backgroundBlur, shadow), which adds semantic meaning for those parameters in context. Other common parameters (x, y, width, height) remain unexplained but are inferable. Partial compensation.

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

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

The description clearly states 'Create a styled rectangle' with a specific verb and object, and adds 'Full glassmorphism support' to distinguish this from shape-creation siblings like create_line or create_ellipse.

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

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

The description implies usage for rectangles needing styling, especially glassmorphism, but does not explicitly contrast with alternatives (e.g., when to use create_vector instead) nor provide exclusion criteria. The recipe gives a concrete scenario but no explicit 'use when' statements.

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 must carry full burden for behavioral disclosure. However, it only states the action ('create') and omits any details about side effects, permissions, reversibility, or return behavior. For a tool with no annotations, this leaves significant ambiguity about what happens when the tool is invoked.

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 concise and well-structured: a clear one-sentence purpose followed by compact typography tips. Every sentence earns its place, and the formatting makes the key parameter guidance easily scannable.

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 12 parameters, no output schema, and no annotations, the description is far from complete. It covers only three parameters' semantics and provides no information about return values, error scenarios, or what an agent should expect after execution. The tool is more complex than the description supports.

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 has 0% description coverage, so the description must compensate for parameter semantics. It adds meaningful guidance for three parameters (fontStyle allowed values, fontSize contextual ranges, letterSpacing use case) but leaves nine other parameters unaddressed. The provided hints are valuable for the core typography controls, making this a partial compensation.

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

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

The description clearly states 'Create a text node with full typography control,' using a specific verb and resource that distinguishes it from sibling tools like create_line or create_frame. It unambiguously communicates the tool's function.

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

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

The description implies usage for creating text but does not explicitly compare with alternatives or state exclusions. It does provide useful typography guidelines (fontSize ranges, letterSpacing usage) that help agents choose appropriate parameter values, but lacks explicit 'use this when' or 'not for' 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 full burden; it explains closed-path fill behavior vs open-path stroke/noFill, gives example gradient and shadow object structures, and mentions windingRule options. It does not disclose return value or coordinate details, but the core behaviors are well covered.

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?

Well-organized with clear section headers for wave/area chart and custom icon recipes, front-loaded with the core purpose. Despite length, each line provides actionable examples and earning its place; there's no fluff.

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 16-param tool with no annotations and no output schema, the description covers the main use cases and key behaviors effectively. It omits return value expectations and some param semantics (width/height auto-sizing), but the rich recipes and concrete examples are sufficient for an agent to invoke the tool correctly in common scenarios.

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 has 0% description coverage for 16 params, so the description must add meaning; it explains pathData syntax, windingRule values, and demonstrates noFill, stroke, strokeWidth, gradient, and shadow through concrete recipes. Many parameters (x, y, opacity, fillOpacity) are not directly explained but they are self-evident from names/defaults; the key vector-specific parameters are covered.

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?

Description states it creates a vector node from an SVG path string, with precise scope ('only way to draw curves, waves, bezier shapes, custom icons, or area charts'), clearly distinguishing from sibling line/rectangle/ellipse 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?

Provides explicit use cases and recipes (closed path with Z for area-under-curve, open path with noFill+stroke for line charts), and names the tool as the only way for curved/bezier shapes. Does not explicitly mention exclusions like using create_line for straight paths, but the 'only way' framing gives adequate guidance.

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