Soma Nexus MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| FIGMA_TOKEN | Yes | Figma personal access token for accessing Figma API. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_figma_fileB | Fetch a Figma file. Prefer compact mode to avoid large payloads. |
| parse_figma_urlA | Parse a Figma URL and extract fileKey and nodeId. |
| validate_figma_to_code_indexA | Validate the global figma-to-code index and all per-component docs before generation. |
| get_figma_nodesB | Fetch specific Figma nodes, their subtrees, and optional geometry. |
| preview_figma_component_mappingB | Preview how a Figma node matches a Design System component via federated docs. |
| generate_flutter_component_from_figmaB | Generate a minimal Flutter widget snippet from a Figma node using federated docs mapping. |
| generate_flutter_page_from_figmaB | Generate Flutter page scaffold from a Figma page/frame URL, using DS components when matched. |
| get_figma_node_from_urlA | Fetch a specific Figma node directly from a full Figma URL. |
| get_figma_node_normalizedA | Fetch a Figma node from URL and return normalized metadata, tokens, styles, and asset refs. |
| get_figma_imagesB | Render Figma nodes to image URLs for assets and previews. |
| get_figma_componentsA | Fetch published components found in a Figma file. |
| get_figma_stylesC | Fetch published styles found in a Figma file. |
| get_figma_variablesB | Fetch local variables and collections from a Figma file. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 13 tools
Multiple tools have overlapping boundaries, especially the node-fetching trio: get_figma_nodes, get_figma_node_from_url, and get_figma_node_normalized all retrieve node data with subtle differences. get_figma_node_from_url and get_figma_node_normalized are particularly confusing since both take a URL and return node information, with the latter adding normalization. This overlap makes it difficult for an agent to reliably select the right tool.
Most tools follow a verb_noun pattern (get_figma_file, generate_flutter_component_from_figma), but there are inconsistencies in granularity and style. For example, get_figma_nodes (plural) coexists with get_figma_node_from_url and get_figma_node_normalized (singular), and the latter two are not parallel to each other. The mix of 'from_url' and 'normalized' suffixes adds unpredictability, so while the convention is readable, it is not consistently applied.
With 13 tools, the server is well-scoped for a Figma-to-Flutter generation workflow. Each tool addresses a distinct step in the pipeline (fetching, parsing, mapping, validating, generating) without unnecessary bloat. The count fits comfortably within the ideal 3-15 range and each tool appears to serve a concrete purpose.
The tool set covers the core lifecycle of Figma-to-Flutter generation: fetching files/nodes/styles/variables, parsing URLs, validating index, previewing component mappings, and generating both component and page code. Minor gaps exist, such as no explicit tool to manage or update the component index or design system docs, but agents can work around these with the existing validation and mapping tools.