Kosmodrom

version_update

Destructive

Creates a product version (without versionID; productID, major and minor are required, the title is built by the server) or changes a version's number, notes or design file (only the passed fields); does not release it. Changes shared product structure; only at the user's request or with their consent. Returns the version.

Input Schema

Name	Required	Description
`build`	No	Build number, from 1; omitted - a "major.minor" version.
`major`	No	Major part of the number.
`minor`	No	Minor part of the number.
`notes`	No	Version notes in Markdown (no HTML), in the language of the workspace data. Replaces the whole field: existing text, `::: doc` sections and `attach:`, `design:`, `color:` tokens stay only if included.
`productID`	No	Product ID of a new version.
`versionID`	No	Version ID; omitted - a new version.
`designFileUrl`	No	Link to the version's Figma file; null or empty - the product's main design file.

Schema Changelog

Changes observed during successful MCP inspections.

Changed11 schema fields changedOct 8, 2026

removedInput schema / $schema

Removed value: -"http://json-schema.org/draft-07/schema#"

changedInput schema / properties / build / description

Previous value: -"New build number, from 1 (there is no build 0)."New value: +"Build number, from 1; omitted - a \"major.minor\" version."

removedInput schema / properties / build / maximum
```
Removed value: -9007199254740991
```

changedInput schema / properties / major / description

Previous value: -"New major part of the number."New value: +"Major part of the number."

removedInput schema / properties / major / maximum
```
Removed value: -9007199254740991
```

changedInput schema / properties / minor / description

Previous value: -"New minor part of the number."New value: +"Minor part of the number."

removedInput schema / properties / minor / maximum
```
Removed value: -9007199254740991
```

changedInput schema / properties / notes / description

Previous value: -"New version notes in Markdown (no HTML), in the language of the workspace data. Replaces the whole field: existing text, `::: doc` sections and `attach:`, `design:`, `color:` tokens stay only if included."New value: +"Version notes in Markdown (no HTML), in the language of the workspace data. Replaces the whole field: existing text, `::: doc` sections and `attach:`, `design:`, `color:` tokens stay only if included."

addedInput schema / properties / productID

Added value: +{
+  "description": "Product ID of a new version.",
+  "format": "uuid",
+  "type": "string"
+}

changedInput schema / properties / versionID / description

Previous value: -"Version ID."New value: +"Version ID; omitted - a new version."

removedInput schema / required
```
Removed value: -[
-  "versionID"
-]
```

First observedOct 6, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already flag destructiveHint=true and readOnlyHint=false, and the description adds value beyond them: it warns that shared product structure is affected and that user consent is required, and it notes partial-update semantics ('only the passed fields'). It does not, however, describe reversibility or what the returned version contains beyond naming it.

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?

A single dense sentence with the create case front-loaded, followed by update scope, the release exclusion, and the consent caveat. Every clause carries information, though the nested parentheticals make it slightly harder to scan.

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 7-parameter mutation tool with no output schema, it covers both modes, the partial-update rule, the consent requirement, and the return value ('Returns the version'). Missing only finer points such as reversibility or what happens to unspecified existing fields on update.

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?

With 100% schema coverage the baseline is 3, but the description compensates with meaning the schema lacks: it states that productID, major and minor are required (the schema lists no required parameters), that versionID's absence triggers creation, that the title is server-built, and that updates are partial. This materially clarifies how to populate the 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 names the verb and resource precisely and covers both operating modes: creating a version (when versionID is absent) and updating number/notes/design file (only the passed fields). It also explicitly bounds scope with 'does not release it,' which routes the agent away from the sibling version_release.

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 a clear conditional for use: 'Changes shared product structure; only at the user's request or with their consent,' plus the implied alternative of version_release for releasing. It stops short of naming version_release outright or spelling out when the create vs. update branch should be chosen.

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

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

Need Help?