Skip to main content
Glama
Sign In

Pixelesq

by com.pixelesq
OverviewDiscussionsAdmin

Import image into assets

upload_asset
Destructive

Import an image into the project's asset library, optimized. Provide EXACTLY ONE of sourceUrl (an http(s) URL the worker fetches) or base64Data (raw base64 image bytes, requires mimeType). Returns the stored asset { id, name, url, type, metadata }; use the returned url as a section media.src. Asset names are unique within a project, so the stored name gets a short tag from the file's content, and optimized images are stored as .webp: rely on the returned name and url, not the requested filename. There is no replace-in-place: to swap an image, upload a new one and repoint media.src. An Unsplash photo (an images.unsplash.com url from search_stock_images) is NOT copied: pass its url as sourceUrl and its stock.downloadLocation, and the tool only reports the use to Unsplash and returns { url, hotlinked: true } to set as media.src as is.

Input Schema

NameRequiredDescriptionDefault
filenameYesDesired filename, e.g. 'hero.jpg'. Names are unique within a project: the stored name gets a short content tag and optimization may store it as .webp, so use the returned asset name/url. Ignored for an Unsplash photo.
mimeTypeNoImage MIME type, e.g. 'image/jpeg'. Required with base64Data; for sourceUrl it is derived from the response.
optimizeNoOptimize/convert before storing (recommended). Default true.
projectIdYesThe project ID
sourceUrlNoPublic http(s) URL of the image to import. The worker fetches the bytes. Provide this OR base64Data, not both. Preferred for anything larger than ~5MB.
base64DataNoRaw base64 image bytes (NOT a data URL). Requires mimeType. Provide this OR sourceUrl, not both. Capped at ~5MB decoded; use sourceUrl for larger images.
downloadLocationNoFor an Unsplash photo from search_stock_images: its stock.downloadLocation. Unsplash asks to be told when one of its photos is used.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedInput schema / properties / base64Data / maxLength
      Added value: +7000000
    • addedInput schema / properties / downloadLocation
      Added value: +{
+  "description": "For an Unsplash photo from search_stock_images: its stock.downloadLocation. Unsplash asks to be told when one of its photos is used.",
+  "type": "string"
+}
    • changedInput schema / properties / filename / description
      Previous value: -"Desired filename, e.g. 'hero.jpg'. Note: optimization may store it as <name>.webp, so use the returned asset name/url."New value: +"Desired filename, e.g. 'hero.jpg'. Names are unique within a project: the stored name gets a short content tag and optimization may store it as .webp, so use the returned asset name/url. Ignored for an Unsplash photo."
  2. First observed

TDQS

A4.2/5.0
Behavior5/5

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

Goes well past the annotations (readOnlyHint=false, destructiveHint=true, openWorldHint=true) by disclosing non-obvious side effects: the stored name gets a content tag and is not the requested filename, images are converted to .webp, names are unique per project, and Unsplash photos are hotlinked rather than copied. It even describes the divergent return shapes ({ id, name, url, ... } vs { url, hotlinked: true }).

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?

Front-loaded with the action, then the source-choice rule, then return usage, then caveats — a sensible priority order with no filler. It repeats the filename/webp caveat that the schema also explains, so it is slightly longer than strictly necessary.

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?

With no output schema, the description helpfully specifies both possible return shapes and how to consume them (media.src). Missing pieces are minor: nothing on auth/permissions, error behavior on fetch failure, or the upload_image distinction.

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 baseline is 3, but the description adds real meaning: it frames the sourceUrl/base64Data pair as mutually exclusive and ties downloadLocation to the Unsplash path and filename to being ignored there. It does not restate size caps, which the schema already carries.

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: importing an image into the project's asset library, with optimization implied. It is clearly distinct from read/manipulation siblings like list_assets or update_asset. However, it never distinguishes itself from the sibling upload_image, which an agent could easily confuse with this tool.

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

Usage Guidelines4/5

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

Gives strong when/how guidance: exactly one of sourceUrl or base64Data, the Unsplash flow with search_stock_images and downloadLocation, and the explicit 'no replace-in-place — upload new and repoint media.src' rule. The one missing routing cue is when to use this versus the sibling upload_image.

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

All Pixelesq toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources