figma_generate_tokens

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 that it 'exports' tokens. It does not clarify whether this is a read-only operation, whether it acts on the current selection or entire file, or how the output is delivered (e.g., download, clipboard, inline response). The lack of any behavioral context beyond the verb leaves significant gaps.

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 concise sentence with no wasted words, which is positive for front-loading. However, it is underspecified for a tool with two parameters and no annotations; brevity is achieved at the expense of necessary detail. It is not overly verbose but fails to be 'appropriately sized' in terms of complete information.

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

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

The description fails to explain what 'export design tokens' concretely means—what is exported, where it comes from, or what the output looks like. There is no output schema and no annotations to fill the gaps. Given that the schema only provides enums without descriptions, the missing context makes the tool hard to use correctly without external knowledge.

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 only partially compensates by listing a few format values (CSS vars, JSON, SCSS) while omitting javascript, typescript, and the tokenTypes parameter entirely. The description does not explain what 'tokenTypes' controls or the distinction between format options. It adds minimal meaning beyond the schema's own enums.

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 and resource: 'Export design tokens' and lists common formats (CSS vars, JSON, SCSS). This distinguishes it from sibling generation tools like figma_generate_css or figma_generate_react, which target code generation rather than token exports. However, it omits the javascript and typescript formats from the parenthetical, slightly underrepresenting the schema's capability.

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 provided about when to use this tool versus alternatives. It does not mention that it should be used for design token extraction rather than node-based CSS generation, nor does it reference any sibling tools. The only implied usage is via the name and formats, but this is not explicit.

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