Skip to main content
Glama

Kosmodrom

by ai.kosmodrom
OverviewDiscussionsAdmin

module_update

Destructive

Creates a product module (without moduleID; productID and title are required) or updates a module's name, description, parent or components, or removes its main Figma frame; omitted fields stay unchanged. Only at the user's request or with their consent: the product structure belongs to the team.

Input Schema

NameRequiredDescriptionDefault
descNoDescription, Markdown
titleNoName
designNonull - remove the module's main Figma frame
moduleIDNoModule ID; omitted - a new module
parentIDNoParent module ID; null - a root module
productIDNoProduct ID of a new module
addComponentIDsNoExisting components to add to the module
removeComponentIDsNoComponents to remove from the module

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changed
    • removedInput schema / $schema
      Removed value: -"http://json-schema.org/draft-07/schema#"
    • changedInput schema / properties / desc / description
      Previous value: -"New description, Markdown"New value: +"Description, Markdown"
    • changedInput schema / properties / moduleID / description
      Previous value: -"Module ID"New value: +"Module ID; omitted - a new module"
    • changedInput schema / properties / parentID / description
      Previous value: -"New parent module ID; null - make it a root module"New value: +"Parent module ID; null - a root module"
    • addedInput schema / properties / productID
      Added value: +{
+  "description": "Product ID of a new module",
+  "format": "uuid",
+  "type": "string"
+}
    • changedInput schema / properties / title / description
      Previous value: -"New name"New value: +"Name"
    • removedInput schema / required
      Removed value: -[
-  "moduleID"
-]
  2. First observed

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already flag destructiveHint=true, but the description adds substantive behavior: partial-update semantics ('omitted fields stay unchanged'), the destructive effects (removing components, removing the main Figma frame), and a consent/permission precondition not present in annotations. It stops short of describing reversibility or what happens to child modules.

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?

Two tightly packed sentences with the create/update distinction and required-field rule front-loaded. The consent clause is a short, high-value second sentence, though the field enumeration after 'or updates a module's' is dense enough to read as a list dump.

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 destructive mutation tool with no output schema and a fully documented input schema, the description covers the create-vs-update branch, patch semantics, side effects, and the consent precondition. It omits permission/auth specifics and the fate of existing children, but nothing critical to correct invocation is missing.

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 adds genuinely new information: productID and title are required for creation (the schema reports zero required params), and it ties moduleID omission to the create path. The remaining parameter notes (design=null, parentID=null) largely restate the schema.

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 two specific verbs (create/update) on a specific resource (product module) and enumerates updatable fields: name, description, parent, components, and Figma frame removal. It clearly distinguishes itself from siblings like product_update and component_update by naming the 'prime module' resource.

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?

Provides a real usage constraint — 'Only at the user's request or with their consent' — which tells the agent when it must not act unilaterally. However, it never routes between create vs. update against alternatives such as product_update or product_modules, and it does not state the condition that selects the create branch beyond 'without moduleID'.

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
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources