GravityPort

asset_update_metadata

Update metadata on a saved asset—tags, prompts, ratings, categories, and reference rights or permitted uses—to keep your AI library organized and clarify how references may be used.

Instructions

Update metadata fields for a saved asset. Pass references to record reference rights and permitted uses for a saved asset; that annotation is not a generation input, so it appends a new recipe snapshot.

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>"
    },
    "name": "asset_update_metadata"
  }
}

Input Schema

Name	Required	Description
`tags`	No
`group`	No
`ratio`	No
`skill`	No
`style`	No
`theme`	No
`prompt`	No
`rating`	No
`assetId`	Yes
`category`	No
`favorite`	No
`references`	No
`user_prompt`	No
`business_fields`	No	Stored with the asset but not searchable; put anything that should be findable via search into tags instead. Only the keys you pass are merged into the stored object: a key whose value is null is removed, and every other stored key is kept unchanged.
`negative_prompt`	No
`recipe_change_summary`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.3.11Nov 11, 2026

TDQS

C2.9/5.0

Behavior3/5

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

The annotations only declare the safety profile (readOnly=false, destructive=false, openWorld=false). The description adds a genuinely non-obvious side effect: passing `references` appends a new recipe snapshot because that annotation is not a generation input. That is real behavioral value beyond the annotations, but it is limited to one field, and the description says nothing about merge semantics, reversibility, or permissions for the other fields.

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?

The description is two sentences with no filler, and the core action is stated first. The second sentence is slightly tangled, with 'that annotation' referring back ambiguously, but it is still compact and readable.

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 16-parameter mutation tool with nested objects and no output schema, so the description should be doing much more work. It covers one parameter's special behavior and leaves the bulk of the surface, including partial-merge behavior and what the caller gets back, undocumented. It is not adequate for a tool of this complexity.

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?

Schema description coverage is only 6% across 16 parameters, so the description must carry meaning. It only explains `references`, where it adds useful intent (rights and permitted uses, not a generation input, triggers a recipe snapshot). The other 15 parameters, including `business_fields` merge semantics, `recipe_change_summary`, and the enum-like `ratio`, `skill`, `style`, and `theme` fields, get no help beyond their bare names.

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?

The description uses a specific verb and resource: 'Update metadata fields for a saved asset'. This clearly scopes the operation to metadata rather than prompts or versions, which is enough for an agent to choose it over siblings such as asset_attach_prompt or asset_version_create. It doesn't explicitly name a sibling it is not, so it falls short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description never says when to use this tool versus alternatives, nor what prerequisites it has (ownership, edit rights, whether trashed assets can be updated). The only usage-like statement is the conditional 'Pass `references` to record reference rights', which is about one parameter, not about when to select the tool. An agent must infer the rest from the name.

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