Skip to main content
Glama

bulk_put_assets

DestructiveIdempotent

Upload 1–200 CMS assets; key = path after /assets/, or sitePath for an exact URL path (e.g. /.well-known/security.txt, /ads.txt). Each item: exactly one of bodyBase64, bodyText (plain text for .css/.js/.mjs/.json/.svg/.txt/.xml only — not .html pages), or importFromUrl. Optional bodySha256 verifies submitted bytes before write; response sha256 is stored bytes (JS/CSS match; WebP rasters may differ). JPEG/PNG/static GIF are re-encoded to WebP (response key photo.webp; /assets/photo.jpg keeps serving it) — use the response key in CSS/JS; optimize:false stores the bytes as sent at your key; animated GIFs are always kept. Uploaded files are live in the editor and draft preview at once; the published site picks them up at the next publish.

Input Schema

NameRequiredDescriptionDefault
siteYesSite slug, e.g. acme-studio
itemsYes
contextYesOne sentence: why you are calling this tool and what you are trying to accomplish. Stored on the site's activity log and visible to everyone on the site — never put secrets or personal data here.
guestTokenNoGuest token from start_site. Send it on every call until claim_site. Omit when this chat is already signed in to Dotsy.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / items / items / properties / sitePath
      Added value: +{
      +  "description": "Store at this exact site path instead of /assets/{key} — e.g. /.well-known/security.txt, /ads.txt, /favicon.ico. Send key OR sitePath.",
      +  "type": "string"
      +}
    • removedInput schema / properties / items / items / required
      Removed value: -[
      -  "key"
      -]
  2. Changed1 schema field changed
    • addedInput schema / properties / items / items / properties / optimize
      Added value: +{
      +  "description": "Default true: a JPEG, PNG or static GIF is re-encoded to WebP (key photo.jpg is stored as photo.webp, and /assets/photo.jpg still serves it). false stores the bytes exactly as sent, at the key given. Animated GIFs are always kept as sent.",
      +  "type": "boolean"
      +}
  3. Changed1 schema field changed
    • addedInput schema / properties / items / items / properties / bodyText
      Added value: +{
      +  "type": "string"
      +}
  4. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations flag destructive/idempotent but the description adds real operational context: JPEG/PNG/GIF re-encoding to WebP with key rewriting, animated GIF preservation, optimize:false pass-through, sha256 pre-write verification vs stored-blob sha256 divergence for rasters, and editor-live/publish-deferred visibility.

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-loads the core action and key/sitePath rule, then layers caveats. It is dense but nearly every clause carries non-obvious behavior; minor tax from long parenthetical asides.

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?

For a mutation tool with no output schema, it covers write semantics, verification, and post-upload visibility well. It could say more about the response shape beyond the returned key/sha256, but the essentials an agent needs are present.

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?

Adds meaning well beyond the 75%-covered schema: the extension whitelist for bodyText (and its .html exclusion), the exactly-one-of body constraint, key-vs-sitePath exclusivity, and the distinction between submitted and stored sha256.

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 verb and resource with scope ('Upload 1–200 CMS assets'), and the naming plus content make it unambiguously distinct from get_asset, list_assets, delete_asset and optimize_assets.

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 clear operating context: bulk range 1–200, key vs sitePath selection, exactly-one-of body field rule, and when to use optimize:false or bodyText. It does not explicitly name a sibling alternative for single-asset uploads or point to optimize_assets, so it stops short of full when/when-not routing.

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