Kosmodrom

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.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "module_update"
  }
}

Input Schema

Name	Required	Description
`desc`	No	Description, Markdown
`title`	No	Name
`design`	No	null - remove the module's main Figma frame
`moduleID`	No	Module ID; omitted - a new module
`parentID`	No	Parent module ID; null - a root module
`productID`	No	Product ID of a new module
`addComponentIDs`	No	Existing components to add to the module
`removeComponentIDs`	No	Components to remove from the module

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedOct 8, 2026

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"
-]
```

First observedOct 6, 2026

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 tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?