Skip to main content
Glama

Kosmodrom

by ai.kosmodrom
OverviewDiscussionsAdmin

design_import

Imports Figma frames into a task, bug or feature through the company's Figma integration, like pasting a design in the web app (snapshot, layers, assets): one entity, up to 10 frame links with node-id per request, large frames 2-3 per request to stay within client timeouts (after a timeout the import keeps running on the server; the entity's designs, by nodeID with ":" such as 12:34, show what was imported within 1-2 minutes); a failed frame does not stop the others. Per frame returns status (imported, updated, unchanged, linked - linked but not refreshed, error), designID and a designToken marker, or error with action - how to fix it; the designToken in an entity's spec or result holds the link to the design, and the same marker in another entity of the product links it there on save. moduleID / componentID (product:structure privilege) set the module's or component's main frame (one frame, no marker); re-import refreshes the snapshot and keeps markers.

Input Schema

NameRequiredDescriptionDefault
framesYesFrames to import
taskIDNoTask or bug ID
taskKeyNoTask or bug number, when the ID is unknown
moduleIDNoModule ID - its main frame (one frame)
featureIDNoFeature ID
featureKeyNoFeature key #F12; not with featureID
componentIDNoComponent ID - its main frame (one frame)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changed
    • removedInput schema / $schema
      Removed value: -"http://json-schema.org/draft-07/schema#"
    • changedInput schema / properties / featureKey / anyOf
      Previous value: -[
-  {
-    "maxLength": 12,
-    "minLength": 1,
-    "type": "string"
-  },
-  {
-    "exclusiveMinimum": 0,
-    "maximum": 9007199254740991,
-    "type": "integer"
-  }
-]New value: +[
+  {
+    "maxLength": 12,
+    "minLength": 1,
+    "type": "string"
+  },
+  {
+    "exclusiveMinimum": 0,
+    "type": "integer"
+  }
+]
    • changedInput schema / properties / featureKey / description
      Previous value: -"Feature key #F12 (or F12, 12); not with featureID"New value: +"Feature key #F12; not with featureID"
    • removedInput schema / properties / taskKey / maximum
      Removed value: -9007199254740991
    • removedInput schema / properties / taskKey / minimum
      Removed value: --9007199254740991
  2. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Goes well beyond the annotations (which only declare non-read-only, non-destructive, open-world). It discloses timeout-and-continue-server-side behavior, partial failure semantics ('a failed frame does not stop the others'), the 1-2 minute delay before designs appear, re-import refresh behavior, and the marker/designToken linkage side effect.

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

Conciseness3/5

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

The core purpose is front-loaded, but the body is a single dense, semicolon-chained block with nested parentheticals that is hard to scan. Every claim is substantive, yet it would benefit from structuring into distinct clauses or a short list.

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?

Despite having no output schema, the description documents the return contract per frame (status values, designID, designToken marker, error with an action for fixing). Paired with complete parameter coverage, an agent has everything needed to call and interpret the tool.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description genuinely adds meaning: nodeID format with ':' (e.g. 12:34), moduleID/componentID setting a main frame with one frame and no marker, and the rule that a designToken in one entity links another entity on save.

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?

States a specific verb and resource ('Imports Figma frames') plus the target entities (task, bug, feature) and the integration it goes through. No sibling tool does this, and the agent can distinguish it immediately even without opening the schema.

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?

Gives clear operational context: 'like pasting a design in the web app', batching guidance (up to 10 links; 2-3 large frames to stay within client timeouts), and the moduleID/componentID single-frame special case. It stops short of naming when NOT to use it or pointing to an alternative sibling, so it lands at 4 rather than 5.

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

All Kosmodrom toolsInspect
Try in Browser
Context Every Agent Can ShareAgents share what they learn, hand off work, and keep it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources