create_text

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

Although no annotations are present, the description discloses a consequential side effect: leading and letter-spacing are automatically computed and applied based on typographic hierarchy, so callers know they cannot control those values independently. It also states the emoji restriction as a hard behavioral constraint. It does not mention return values or selection effects, but the disclosed behavior goes well beyond what the schema alone would communicate.

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, all dense with information: purpose/placement, hard constraint and alternative, and automatic typography behavior. No filler, no repetition of schema properties, and the most important scoping constraint is front-loaded.

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

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

For a 9-parameter create operation with no annotations and no output schema, the description is nearly complete: it covers placement, the emoji edge case, and the automatic styling behavior. The main residual gaps are return/created-node semantics and error behavior for violations, but the fully-described schema covers the remaining parameter details.

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

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

Schema description coverage is 100%, so the schema already documents all 9 parameters; the baseline is therefore 3. The description adds useful semantic context for text (no emojis) and implies that fontSize and fontFamily participate in automatic leading/tracking, but it does not add per-parameter 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?

The description uses a specific verb-resource pair — 'Create a styled text element' — and specifies placement ('on the Figma canvas or inside a container'). It also differentiates itself from the sibling create_svg_icon by explicitly reserving vector icons/emojis for that tool.

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

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

It gives explicit when-not guidance: emojis are strictly disallowed, and create_svg_icon is named as the alternative for vector icons. The placement context (canvas or container) also clarifies the intended invocation scope, so there is no ambiguity about when this tool should be chosen over its icon-oriented sibling.

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