Skip to main content
Glama
Sign In
Figxel

Figxel

by AvYour
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

How to work in Figma (skills)

figma_get_guide
Read-only

Read this before a design, motion or review task. Returns a skill — the playbook for one kind of work — as Markdown. No arguments gives workflow (the designer's loop).

Instructions

Read this before a design, motion or review task. Returns a skill — the playbook for one kind of work — as Markdown. No arguments gives workflow (the designer's loop). State the role and the gear first: screens and flows read ux, posters, ads, print and icons graphic, logos brand; a page or more also runs design. A motion piece starts with storyboard, keyframes with motion, and a review with critique. topic names a skill (workflow, design, storyboard, motion, critique, design-system, design-to-code, code-to-design, prototype, figjam, slides, brand, graphic, ux) or one of its sections (spec is the figma_create_from_spec grammar); section picks a section of that skill; "skills" lists every skill with what it is for and its sections. Every answer ends with the exact calls for the skill's other sections and for the other skills. Works without the plugin. Under BRIDGE_PROCESS=strict new work waits for its role skill and figma_set_brief, keyframes for the motion skill.

Input Schema

NameRequiredDescriptionDefault
topicNoA skill, one of its sections, or "skills". Default "workflow".
sectionNoA section of the skill named by topic; every answer's footer lists them.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.3.0
    • changedInput schema / properties / topic / enum
      Previous value: -[
-  "workflow",
-  "design",
-  "storyboard",
-  "motion",
-  "critique",
-  "design-system",
-  "design-to-code",
-  "code-to-design",
-  "prototype",
-  "figjam",
-  "slides",
-  "build",
-  "spec",
-  "check",
-  "safety",
-  "tools",
-  "brief",
-  "directions",
-  "system",
-  "tells",
-  "finish",
-  "beat-sheet",
-  "boards",
-  "animatic",
-  "bible",
-  "easing",
-  "principles",
-  "transitions",
-  "kinetic-type",
-  "formats",
-  "passes",
-  "mechanics",
-  "lenses",
-  "motion-checks",
-  "sampling",
-  "rounds",
-  "library",
-  "typography",
-  "rules",
-  "board-recipes",
-  "deck-recipes",
-  "skills"
-]New value: +[
+  "workflow",
+  "design",
+  "storyboard",
+  "motion",
+  "critique",
+  "design-system",
+  "design-to-code",
+  "code-to-design",
+  "prototype",
+  "figjam",
+  "slides",
+  "brand",
+  "graphic",
+  "ux",
+  "build",
+  "spec",
+  "check",
+  "safety",
+  "tools",
+  "brief",
+  "directions",
+  "system",
+  "tells",
+  "finish",
+  "beat-sheet",
+  "boards",
+  "animatic",
+  "bible",
+  "easing",
+  "principles",
+  "transitions",
+  "kinetic-type",
+  "formats",
+  "passes",
+  "mechanics",
+  "lenses",
+  "motion-checks",
+  "sampling",
+  "rounds",
+  "library",
+  "typography",
+  "rules",
+  "board-recipes",
+  "story",
+  "deck-recipes",
+  "identity",
+  "guidelines",
+  "placements",
+  "grid",
+  "illustration",
+  "flows",
+  "screens",
+  "states",
+  "accessibility",
+  "content",
+  "usability",
+  "skills"
+]
  2. First observedv0.1.1

TDQS

A4.9/5.0
Behavior5/5

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

The read-only annotations already establish safety, and the description adds useful context: the response is Markdown, it works without the plugin, every answer includes footer calls for related sections and skills, and strict mode changes when work may begin.

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

Conciseness4/5

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

The description is front-loaded with the core instruction and every sentence carries useful routing or behavioral information. It is dense and somewhat run-on, especially the long topic list and role mapping, but the complexity is justified by the large enum and the need to route agents correctly.

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

Completeness5/5

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

For a two-parameter, read-only guidance tool with no output schema, the description covers what is returned, how to choose the topic, how section works, the default, the footer behavior, plugin independence, and strict-mode implications. Nothing material is missing for correct invocation.

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

Parameters5/5

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

Although schema coverage is 100%, the description adds substantial meaning beyond the enum by mapping work types to topics, such as screens and flows to ux, posters and icons to graphic, logos to brand, and motion work to storyboard or motion. It also clarifies that section selects a section within the chosen skill and that skills lists all available skills.

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

Purpose5/5

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

The description states a specific verb and resource: it reads and returns a skill playbook as Markdown. It clearly distinguishes this documentation-retrieval tool from the many sibling action tools by explaining that it returns guidance rather than performing a Figma edit.

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

Usage Guidelines5/5

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

It explicitly says to read this before design, motion, or review tasks, and maps roles and work types to the correct topic values. It also explains the default behavior with no arguments and notes the strict-process dependency on role skills and figma_set_brief.

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

Deploy Server

Other Tools