GravityPort

asset_version_create

Create a new child version of an existing asset to record recipe changes without overwriting the parent or its original image.

Instructions

Save a new recipe version as a child of an existing asset without overwriting the parent.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "assetId": "<assetId>",
      "version_change": "<version_change>"
    },
    "name": "asset_version_create"
  }
}

Input Schema

Name	Required	Description
`tags`	No
`group`	No
`ratio`	No
`skill`	No
`style`	No
`theme`	No
`prompt`	No
`rating`	No
`source`	No	Optional provenance for a replacement image, such as generation_tool, model, or codex_session_id.
`assetId`	Yes	Existing parent asset ID.
`category`	No
`favorite`	No
`imagePath`	No	Optional new image path; must be an absolute path on this machine (any local folder is accepted, same as asset_create). When omitted, the parent image is copied for a recipe-only version.
`assetIdNew`	No	Optional ID for the new version.
`references`	No
`sourceType`	No
`user_prompt`	No	Optional user request kept separately from the effective generation prompt.
`version_change`	Yes	Required summary of what changed from the parent.
`business_fields`	No	Stored with the asset but not searchable; put anything that should be findable via search into tags instead.
`negative_prompt`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.3.11Nov 11, 2026

TDQS

C2.9/5.0

Behavior2/5

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

Annotations already declare readOnlyHint=false and destructiveHint=false, so 'without overwriting the parent' largely restates the structured contract rather than adding to it. Nothing is said about what fields are inherited from the parent, what happens to fields omitted from the 20-parameter body, or whether a version ID is returned for later use.

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 front-loaded sentence with no filler or repetition. It is arguably undersized for a 20-parameter mutation, but every word present earns its place.

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?

This is a 20-parameter, nested-object, non-idempotent-looking mutation with no output schema, and the description covers only the parent/child relationship. Inheritance behavior, what the caller receives back, and how to use imagePath versus a recipe-only version are all left unstated at the description level.

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 20 parameters and only 35% schema description coverage, the description needs to compensate and does not — tags, business_fields, references, source, imagePath, and the required version_change are all unaddressed. The schema itself documents the highest-risk fields (imagePath, references rights, business_fields), but a large undeclared remainder is left to the caller.

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?

States a specific verb and resource ('Save a new recipe version') plus the structural relationship ('as a child of an existing asset'), which separates it conceptually from asset_create and asset_update_metadata. It stops short of naming any sibling, so differentiation still requires inference.

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 phrase 'without overwriting the parent' implies the usage case: create a new version instead of mutating in place. No explicit when-to-use, no when-not-to-use, and no named alternative (asset_create vs asset_duplicate vs asset_restore) despite several plausible siblings.

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