Skip to main content
Glama

asset_upload

DestructiveIdempotent

Upload local image files to the site's media library without attaching them, and receive asset IDs and derivative sizes for building responsive srcsets.

Instructions

Upload local image files into the site's media library (POST /assets -> PUT bytes -> PUT confirm) WITHOUT attaching them to anything. Use for images referenced from site.data / page.data maps, article galleries or template markup; use product_set_images when the images are a product's gallery.

Returns each asset's id, dimensions, public path (/photos/) and the derivative sizes Voog actually produced — build srcsets from those widths, never from guessed ones (a width Voog did not make answers 403 and the browser renders nothing). Voog caps the LONG side of each derivative at 150/600/1280/2048 and scales the other side to match the source aspect ratio, so a wide image's derivatives are capped on WIDTH, not height.

By default an existing asset with the same filename is REUSED rather than uploaded again: Voog auto-suffixes duplicate filenames (photo-1.jpg), so re-uploading silently orphans the original. Pass allow_duplicate=true to force a new asset (e.g. a corrected re-shoot under a fresh sequence letter).

Waits for Voog to finish its async resizes before returning — up to 120s per file, polling the API every 5s, so a large batch is slow by design. Each result carries sizes_complete: false means the wait timed out and sizes is PARTIAL, so build the srcset from a later read rather than from those widths. Pass wait_for_sizes=false to skip the wait entirely (then sizes is empty).

Do NOT request a derivative URL over HTTP to check whether it exists — a too-early request gets a 403 that the CDN caches for ~1h, breaking a URL that was about to work.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
siteYesSite name from voog_list_sites
filesYesAbsolute paths to local image files (.gif, .jpeg, .jpg, .png, .webp)
wait_for_sizesNoWait for Voog's async resizes before returning (default true). false returns as soon as the upload is confirmed — `sizes` may then be empty.
allow_duplicateNoUpload even when an asset with this filename already exists (default false = reuse it)
Behavior5/5

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

Goes well beyond the annotations by detailing the multi-step POST/PUT/PUT flow, the 120s async polling and 5s interval, the 150/600/1280/2048 derivative caps, the duplicate reuse/suffix orphaning behavior, and the CDN 403 caching pitfall. It also clarifies that sizes_complete=false indicates partial results after timeout. No contradiction with annotations.

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?

The description is long but every sentence serves a purpose: it covers the multipart workflow, sibling discrimination, output format, derivative sizing rules, duplicate behavior, timeout semantics, and a CDN caching warning. It is structured in focused paragraphs and front-loaded with the core operation.

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?

Given the tool's complexity (upload plus async resize, duplicate handling, partial results, CDN side effects) and the absence of an output schema, the description fully discloses the return value shape (id, dimensions, public path, sizes), the 'sizes_complete' flag, and the consequences of HTTP HEAD checks. It anticipates the likely failure modes and tells the agent exactly how to use and interpret the tool.

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?

Despite 100% schema coverage, the description enriches each parameter: files are 'absolute paths' with supported extensions, allow_duplicate and wait_for_sizes receive behavioral consequences (e.g., 'Pass allow_duplicate=true to force a new asset', 'Pass wait_for_sizes=false to skip the wait'). The duplicate-risk explanation adds meaning beyond the schema's raw defaults.

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?

The opening sentence states 'Upload local image files into the site's media library' and explicitly distinguishes from product_set_images with 'use product_set_images when the images are a product's gallery.' It names the exact resource (media library) and verb (upload), making the tool's scope unambiguous.

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?

The description explicitly says 'Use for images referenced from site.data / page.data maps, article galleries or template markup; use product_set_images when the images are a product's gallery.' It also explains when to set allow_duplicate=true (forced re-upload) and wait_for_sizes=false (skip wait), giving clear decision criteria.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/runnel/voog-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server