Skip to main content
Glama

dreamlayer_upload_image

Upload a local image file to use as a reference for editing, background removal, upscaling, or sprite animations. Returns an asset ID for reuse in subsequent image tasks.

Instructions

Use when an edit, background removal, upscale or sprite animation needs a local reference. Requires an absolute path to PNG, JPEG, WebP or supported camera RAW, up to 200 MB. Uploads that file and returns input_asset_id; starts no paid work. Reuse the asset ID for recovery. Not needed for text-to-image. If upload fails, fix the input or retry upload only.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathYesAbsolute path to a PNG, JPEG, WEBP, or camera RAW.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
errorNo
expires_atNo
input_asset_idNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "additionalProperties": true,
      +  "properties": {
      +    "error": {
      +      "properties": {
      +        "execution_id": {
      +          "type": [
      +            "string",
      +            "null"
      +          ]
      +        },
      +        "idempotency_key": {
      +          "type": "string"
      +        },
      +        "reason": {
      +          "type": "string"
      +        },
      +        "request_id": {
      +          "type": [
      +            "string",
      +            "null"
      +          ]
      +        },
      +        "retryable": {
      +          "type": "boolean"
      +        }
      +      },
      +      "required": [
      +        "reason",
      +        "retryable"
      +      ],
      +      "type": "object"
      +    },
      +    "expires_at": {
      +      "type": "string"
      +    },
      +    "input_asset_id": {
      +      "type": "string"
      +    }
      +  },
      +  "type": "object"
      +}
  2. First observedv0.2.0

TDQS

A4.7/5.0
Behavior4/5

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

Annotations already carry hints, and the description adds meaningful context: no paid work is started, the returned ID can be reused for recovery, and retry behavior on failure is scoped. It does not contradict annotations and adds cost/safety behavior beyond them.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four sentences, each earning its place: opening use case, input constraints, behavior/result, and error handling. The most important decisions (when to use, path constraints) are front-loaded, with no filler.

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 single-parameter upload tool, the description covers prerequisites, limits, cost impact, return value, reuse, and failure handling. The output schema exists, so return-value details don't need to be spelled out further.

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?

Schema coverage is 100%, so the baseline is a 3, but the description adds the 200 MB size cap and reinforces absolute path and accepted formats. These constraints are useful for validating input before invocation beyond what the schema states.

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?

States a specific action ('upload') on a concrete resource (local image file) with a clear outcome (returns input_asset_id). It distinguishes itself from generate by saying it is not needed for text-to-image, making the tool's role unmistakable among siblings.

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 says when to use it (edits, background removal, upscale, sprite animation needing a local reference) and when not (text-to-image). Also gives failure-mode guidance ('fix the input or retry upload only'), so an agent knows exactly how to proceed.

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