GravityPort

asset_create

Import an image from an absolute path into the GravityPort library and attach prompt recipe metadata; duplicate image bytes return the existing asset.

Instructions

Copy an image into the GravityPort library and save prompt recipe metadata. The image path must be an absolute path on this machine. Symbolic links are rejected. Only supported image and video formats are imported. Identical bytes already in the library (outside Trash) return the existing asset with deduplicated: true instead of creating a copy.

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": {
      "imagePath": "<imagePath>"
    },
    "name": "asset_create"
  }
}

Input Schema

Name	Required	Description
`tags`	No	Tags saved with the asset; searchable.
`group`	No	Group the asset is filed under; grouping, not a project.
`ratio`	No
`skill`	No
`style`	No
`theme`	No
`prompt`	No
`rating`	No	Star rating from 0 (unrated) to 5.
`source`	No	Optional generation provenance, such as generation_tool, model, codex_session_id, or codex_thread_id. The original image path and Codex task ID are detected automatically.
`category`	No	Category label shown in the app.
`favorite`	No	Mark the asset as a favorite.
`imagePath`	Yes	Absolute path of the image on this machine.
`references`	No
`sourceType`	No	Optional source type. Defaults to codex-generated for images under <CODEX_HOME>/generated_images (normally the user's .codex/generated_images), and to mcp-agent (an image saved by an AI assistant, shown as "AI 助手" in the App) for everything else.
`user_prompt`	No	Optional user request kept separately from the effective generation prompt.
`version_change`	No
`business_fields`	No	Stored with the asset but not searchable; put anything that should be findable via search into tags instead.
`negative_prompt`	No
`parent_asset_id`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.3.11Nov 11, 2026

TDQS

A3.7/5.0

Behavior4/5

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

Beyond the annotations (readOnly=false, destructive=false, openWorld=false), the description discloses meaningful behavior: symlinks are rejected, unsupported formats are refused, and identical bytes outside Trash return the existing asset with deduplicated: true. That dedup return semantic is especially valuable given there is no output schema, though permissions and failure modes are not covered.

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?

Four tight sentences, front-loaded with the core action then the constraints, with no filler. The deduplication sentence is slightly dense but earns its place as the only disclosure of return behavior.

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 19-parameter mutation tool with nested objects and no output schema, the description covers the highest-risk concerns: path validity, format support, and what happens on duplicate content. Remaining gaps are the many optional metadata parameters and permission requirements, which keeps it short of fully complete.

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

Parameters3/5

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

The description adds real meaning for imagePath (must be absolute, on this machine) and explains the dedup outcome, but with 19 parameters at 53% schema coverage it leaves many fields — version_change, parent_asset_id, ratio, skill, style, negative_prompt — undocumented in either place. It compensates partially, not fully.

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 — copy an image into the GravityPort library — plus the secondary effect of saving prompt recipe metadata. It is clear what the tool does, but it never names or contrasts with siblings such as asset_import_folder or asset_duplicate, so an agent must infer which creation path applies.

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?

Usage is implied through stated preconditions (absolute path, no symlinks, supported formats), which does help an agent decide whether a call will succeed. However, there is no explicit when-to-use versus when-not guidance and no routing to alternatives like asset_import_folder for bulk ingestion or asset_duplicate for existing assets.

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