Soma Nexus MCP

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation2/5
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.
Naming Consistency3/5
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.
Tool Count5/5
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.
Completeness4/5
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.
Average 3.3/5 across 13 of 13 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already signals this is a safe read operation. The description adds no additional behavioral context such as pagination, response format, or error handling.
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 a single concise sentence with no fluff. However, it is so sparse that it sacrifices valuable context for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and minimal parameter information, the description is inadequate. It does not disclose return values or clarify the impact of optional parameters, making it incomplete for a tool with three parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries full responsibility. It does not explain the purpose of responseMode (standard/compact) or debugTelemetry, leaving the agent without meaningful parameter semantics.
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 uses the specific verb 'Fetch' and identifies the resource as 'published styles' in a Figma file, clearly distinguishing it from sibling tools like get_figma_components and get_figma_variables.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention exclusions or scenarios where another sibling tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a safe read-only operation. The description adds a behavioral warning about large payloads and suggests compact mode to mitigate this, which is useful context beyond the annotations. However, it does not disclose other behaviors like return format or versioning semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences that front-load the action and purpose. Every word contributes, with no redundancy or filler, achieving maximum clarity in minimal space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description does not explain the return structure or contents beyond 'a Figma file.' Given the tool has 4 parameters and a warning about payload size, more context is needed about what the response includes, version handling, and parameter semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description only minimally references 'compact mode' related to the responseMode enum. It does not explain fileKey, version, or debugTelemetry, leaving the agent to infer from parameter names alone. This insufficiently compensates for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches a Figma file, using a specific verb and resource. It distinguishes from siblings like get_figma_nodes or get_figma_images by targeting the whole file, though it does not explicitly mention scope beyond 'a Figma file'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like get_figma_nodes or get_figma_images. The advice to prefer compact mode is about parameter selection, not tool selection, and no exclusions or alternative tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, covering the safety profile. The description adds some context about retrieving subtrees and optional geometry, but it does not disclose other behavioral aspects like response format, size limits, or pagination.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly-worded sentence with no filler. It is front-loaded with the main purpose and every word contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 parameters, no output schema, and no parameter descriptions, the one-sentence description is insufficient. It does not explain return values, parameter semantics, or when to invoke this tool, making it inadequate for reliable agent selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining parameters. It vaguely references 'specific Figma nodes' (nodeIds) and 'optional geometry' (geometry), but it does not mention fileKey (required), depth, version, responseMode, or debugTelemetry, leaving most parameters unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Fetch') and resource ('specific Figma nodes') with scope ('subtrees', 'optional geometry'). It is clear but does not explicitly differentiate from sibling tools like get_figma_node_from_url or get_figma_file.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as get_figma_file or get_figma_node_normalized. It lacks any context about prerequisites, use cases, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds the behavioral detail that matching occurs 'via federated docs,' but it does not disclose output format, error behavior, or what 'preview' returns. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence with the verb and object front-loaded. There is no filler or repetition, so it earns top marks for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 6 parameters, no output schema, and only a readOnlyHint annotation, the description is too thin to be complete. It does not explain what the preview returns (e.g., match candidates, confidence scores) or how the parameters affect behavior, making it insufficient for confident invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter meaning. It only hints at figmaUrl via 'Figma node' and says nothing about depth, version, responseMode, maxCandidates, or debugTelemetry. This leaves the agent without critical parameter guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Preview') and identifies the resource ('how a Figma node matches a Design System component via federated docs'). This distinguishes it from sibling get/generate tools, though 'federated docs' is somewhat jargon-y.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives like get_figma_components or generate_flutter_component_from_figma. The description implies a use case but provides no conditional context, exclusions, or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds that the output is image URLs, which is not covered by the readOnlyHint and openWorldHint annotations. It does not disclose rate limits, authentication needs, or error behaviors, but annotations already establish it as a safe read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that conveys the essential function without unnecessary detail. It is well-structured and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and the presence of seven parameters, the description is far too brief. It does not explain the return value format, the relationship between nodeIds and rendering, or any edge cases, 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.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description provides no meaningful explanation of parameters such as fileKey, nodeIds, scale, format, or responseMode. It only generically mentions 'nodes' and 'image URLs', leaving the agent to guess the purpose and constraints of each parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool renders Figma nodes to image URLs, specifying its purpose and distinguishing it from sibling tools like get_figma_nodes or generate_flutter_component_from_figma. It covers the core function without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: when image URLs for Figma nodes are needed for assets or previews. However, there is no explicit mention of when not to use this tool or comparison with alternatives, leaving the decision to the agent's inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation is consistent with the description, and the description adds that it fetches both variables and collections. However, it does not disclose any additional behavioral traits like response format, pagination, or constraints. With annotations covering the read-only nature, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the verb and resource, with zero redundant words. It earns its place despite being minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema and three parameters including an enum, the description should at least hint at return values or parameter behavior. It only states the core fetch operation, leaving important details like responseMode semantics undefined, making the tool underspecified for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description needed to compensate by explaining fileKey, responseMode, and debugTelemetry. It mentions none of these parameters, leaving the agent with no semantic meaning beyond the raw schema fields and enum values.
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 uses the specific verb 'Fetch' and identifies the resource as 'local variables and collections' from a Figma file, clearly distinguishing it from siblings like get_figma_styles or get_figma_components. This makes the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives such as get_figma_styles or get_figma_components. The description simply states what it does without any context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true, so the tool's safe read-only nature is known. The description adds one behavioral detail: 'using DS components when matched,' indicating a matching behavior. However, it does not disclose what happens on no match, whether it writes to disk, or the nature of the output (code scaffold details), leaving significant behavioral aspects unexplained.
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 a single concise sentence that front-loads the core purpose without unnecessary padding. It is appropriately sized for stating the main function, though could benefit from an additional sentence on parameters or output without becoming verbose. It earns a high score for efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 6 parameters, no output schema, and no parameter documentation in the schema. The description only provides the high-level purpose and a hint about DS component matching. It does not explain what the generated scaffold contains, what constraints apply, or how the various parameters influence behavior, making it inadequate for an agent to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only alludes to the 'Figma page/frame URL' parameter via the main purpose. The other five parameters (depth, version, maxNodes, responseMode, debugTelemetry) are entirely undocumented in both the description and the schema descriptions. The description fails to compensate for the lack of schema-level parameter documentation.
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 clearly states the verb ('Generate'), the resource ('Flutter page scaffold'), and the source ('Figma page/frame URL'). It also distinguishes from sibling tools like generate_flutter_component_from_figma by focusing on page-level generation and mentions the use of DS components, making the purpose specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for generating Flutter page scaffolds from Figma URLs, which provides clear context. However, it does not explicitly state when to use this tool over alternatives (e.g., generate_flutter_component_from_figma) or provide exclusion criteria. There is no direct mention of alternatives or when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true already informs the agent this is a safe read operation. The description adds context about 'minimal' output and 'federated docs mapping', but does not clarify what that mapping entails or any limitations. It does not contradict annotations.
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 a single, front-loaded sentence with no waste. However, it is efficient at the cost of omitting important details, so it earns a 4 rather than 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 5 parameters, no output schema, and no parameter descriptions, the description is too minimal. It fails to explain the output format, the behavior of optional parameters, or the 'federated docs mapping' concept, leaving significant gaps for an agent to safely invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% parameter description coverage, so the description must compensate. It only indirectly refers to figmaUrl via 'Figma node' but leaves depth, version, responseMode, and debugTelemetry completely unexplained, leaving agents without meaning for these parameters.
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 clearly states the tool's verb ('Generate'), resource ('Flutter widget snippet'), source ('Figma node'), and method ('federated docs mapping'). It distinguishes itself from sibling tools like generate_flutter_page_from_figma by targeting components vs pages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for generating small widget snippets from Figma nodes, but it does not explicitly state when to use this instead of other tools such as get_figma_nodes or generate_flutter_page_from_figma. No prerequisites or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, so the read-only safety is covered. The description adds output composition and normalization, but it does not disclose behaviors like URL parsing, failure modes, or what 'normalized' entails beyond the listed categories.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the verb and object. Every word earns its place, with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With six parameters, no output schema, and 0% schema description coverage, the description must explain invocation details. It only vaguely lists output categories, leaving the agent to guess about depth, responseMode, includeRawNode, and other parameter semantics. This is inadequate for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description provides no explanation of the six parameters (figmaUrl, depth, version, responseMode, debugTelemetry, includeRawNode). The schema gives names/types/enums, but the description adds no meaning, making it insufficient for understanding parameter effects.
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 uses a specific verb ('Fetch') and resource ('Figma node from URL') and enumerates the output items (metadata, tokens, styles, asset refs). The word 'normalized' distinguishes this from sibling tools like get_figma_node_from_url or get_figma_nodes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternative tools are mentioned. The term 'normalized' implies a particular use case (processed data vs raw), but there is no exclusions or comparative guidance against siblings like get_figma_node_from_url, get_figma_nodes, or parse_figma_url.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already declares this as a safe read operation, and the description adds that it extracts fileKey and nodeId. However, it does not disclose behavior for malformed URLs or URLs without a nodeId, which is useful context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence that immediately states the purpose and outputs. Every word earns its place; there is no waste or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, read-only parsing tool with one parameter, the description covers the essential return values (fileKey and nodeId). While no output schema exists, the mention of these two outputs provides adequate context. A minor gap is not explaining whether nodeId is optional or always present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. The phrase 'Figma URL' adds little beyond the schema's 'figmaUrl' name and 'uri' format. It does not specify accepted URL patterns (e.g., /file/ vs /design/) or how to handle missing nodeId.
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 explicitly states the action ('Parse a Figma URL') and the specific outputs ('extract fileKey and nodeId'). This clearly distinguishes it from sibling tools that fetch entities or perform other operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like get_figma_node_from_url or get_figma_file. The description does not mention any prerequisites, exclusions, or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds a scoping constraint by specifying 'published' components, indicating that unpublished components are excluded. This is behaviorally relevant and goes beyond the readOnlyHint annotation, which already signals a safe read operation. However, it does not disclose response format or pagination behavior, though the annotation lowers the bar for such details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence of six words, directly stating the core action. Every word contributes meaning, with no redundant or filler content. It is optimally concise for the stated purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with three parameters and no output schema, the description covers only the basic action without explaining key behavioral options like responseMode. It also omits any context about what the returned components look like or how the tool fits into the broader component generation workflow. The description is minimally viable but leaves clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description only vaguely maps to the 'fileKey' parameter through the phrase 'Figma file'. It provides no meaning for 'responseMode' (standard vs compact) or 'debugTelemetry', leaving two of three parameters undocumented in prose. This is a significant gap given the low schema coverage.
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 uses a specific verb ('Fetch') and resource ('published components') within a 'Figma file', clearly identifying what the tool returns. It differentiates from sibling tools like get_figma_styles and get_figma_images by naming 'components' as the target. This is a clear and specific purpose statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when one needs published components from a Figma file, but it does not explicitly state when to use this tool over alternatives such as get_figma_styles or get_figma_nodes. No exclusions or alternative tool references are given, leaving usage guidance implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is known. The description adds minimal behavioral context beyond the input format; it doesn't disclose error handling, return structure, or rate limits. This is acceptable but not enriched beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. It efficiently conveys the core action and input requirement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With six parameters, no output schema, and no parameter descriptions, the description is minimal. It covers the primary use case but lacks detail on optional parameters, expected return values, and potential errors, making it incomplete for complex usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter meaning, but it only clarifies figmaUrl. The other five parameters (depth, version, geometry, responseMode, debugTelemetry) remain undocumented in both schema and description, leaving a significant gap.
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 clearly states a specific verb ('Fetch'), a specific resource ('a specific Figma node'), and the source ('directly from a full Figma URL'). This distinguishes it from sibling tools like get_figma_nodes (which likely takes separate file/key and node IDs) and parse_figma_url (which parses URLs), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case: when you have a full Figma URL and need to extract a specific node. It doesn't explicitly mention alternatives or exclusions, but the context of sibling tools (e.g., get_figma_nodes, parse_figma_url) plus the phrase 'directly from a full Figma URL' gives strong contextual guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the non-destructive nature is known. The description adds context about the scope (global index and per-component docs) and timing, but does not disclose what validation checks are performed, what the return format is, or failure behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that is front-loaded and contains no filler. It communicates the essential operation, scope, and timing efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should at least hint at what the validation returns or how to interpret results. It also does not clarify success/failure behavior or prerequisites. The timing context ('before generation') is helpful, but the tool's behavior beyond 'validate' is under-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description provides no information about the two parameters. The parameter names and enum values are somewhat self-explanatory, but the distinction between 'standard' and 'compact' response modes and the effect of debugTelemetry is not explained, leaving a significant gap.
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 uses a specific verb ('validate') and clearly identifies the resource ('global figma-to-code index and all per-component docs') and timing ('before generation'). This clearly distinguishes it from sibling tools that fetch, parse, or generate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: 'before generation.' This provides clear contextual guidance, though it does not name specific alternative tools or explicitly state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![soma_nexus MCP server](https://glama.ai/mcp/servers/pablostefan/soma_nexus/badges/card.svg)](https://glama.ai/mcp/servers/pablostefan/soma_nexus)

Score Badge

Copy to your README.md:

[![soma_nexus MCP server](https://glama.ai/mcp/servers/pablostefan/soma_nexus/badges/score.svg)](https://glama.ai/mcp/servers/pablostefan/soma_nexus)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/pablostefan/soma_nexus'

If you have feedback or need assistance with the MCP directory API, please join our Discord server