Skip to main content
Glama

Add style set image

add_style_sample

Add one image to the user's active style kit (a style holds any number of images per type and size; the user picks one as the anchor in Create with AI). subject_category sets the type it frames and replaces that type's anchor (its first image) at that size; add:true keeps the anchor and adds the image beside it; no subject_category adds an untagged image. image_id replaces that exact image. remove:true removes image_id (or, without it, the first image of subject_category at that size). With a MagicPixel style active, uploading makes the user's own copy of it (its images and brief) and activates it; with No style it creates "My style". The result says which. remove never creates one. Rules match the in-app editor: size 128 accepts a 128/256/512/1024 square on an exact 128-pixel grid (stored at 128); size 64 must be exactly 64×64; no soft (partly transparent) edges; max 2 MB. The active style's images steer the look and pixel size of EVERY generation (account-wide), unlike style_reference_id which only guides one call. Seed them from the game's existing art. The user edits the same images in the app (the style picker in Create with AI, ✎ on the style).

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": "add_style_sample"
  }
}

Input Schema

NameRequiredDescriptionDefault
addNoWith subject_category: add a further image of that type instead of replacing its anchor.
sizeNoSize band the image calibrates (64 or 128). Omitted → 128.
removeNoRemove image_id (or the type's first image at that size) instead of uploading.
image_idNoA kit image id from get_style_set: replace it (with image_base64) or remove it (with remove).
image_base64NoPNG or JPEG (raw base64 or data URL). Required unless remove is true.
subject_categoryNoThe type the image frames (custom = untagged). A type without an image reads the next one in this order at the same size. Omitted → custom, or the replaced image's own type.

Schema Changelog

Changes observed during successful MCP inspections.

No schema history has been recorded yet.

TDQS

A4.9/5.0
Behavior5/5

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

Annotations only supply readOnly=false, idempotent=false, destructive=false, openWorld=false, so the description carries most of the burden and delivers: copy-on-upload of a MagicPixel style, auto-creation of 'My style', activation side effects, and the account-wide blast radius on EVERY generation. It also discloses validation constraints (grid, exact dimensions, transparency, 2 MB) and notes 'remove never creates one'. Minor tension with destructiveHint=false since remove:true deletes an image, but removal is disclosed and scoped rather than contradicted.

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?

Dense but nearly every clause carries behavior or a constraint; the purpose and default behavior are front-loaded. It is one long unstructured block, though, making the remove/replace/add branches harder to scan than a short enumerated form would be.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutating, side-effect-heavy tool with no output schema, the description covers preconditions, branching semantics, validation rules, side effects, and even says the result reports whether a style was created or copied. Nothing an agent needs to call it correctly is missing.

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

Parameters5/5

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

Schema coverage is already 100%, yet the description adds real semantic weight beyond the schema: what 'anchor' means, that omission of subject_category yields an untagged image or inherits the replaced image's type, size-band grid rules (128/256/512/1024 accepted on an exact 128 grid, 64 must be exactly 64×64), and the precedence of image_id over upload. This is meaning an agent cannot derive from the field descriptions alone.

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?

Opens with a specific verb+resource ('Add one image to the user's active style kit') and immediately scopes it against the style-reference alternative. An agent can distinguish it from get_style_set, upload_style_reference, and update_style_profile without opening any schema.

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

Usage Guidelines5/5

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

Explicitly lays out the branching decision tree: subject_category replaces the type's anchor, add:true keeps the anchor and appends, no subject_category adds an untagged image, image_id replaces one exact image, remove:true deletes. It also names when this tool applies vs. style_reference_id ('only guides one call'), which is genuine alternative-routing guidance.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources