Skip to main content
Glama
Sign In

AskYourStack

by com.askyourstack
OverviewDiscussionsAdmin

Upload an image to a connected site

content_upload

Add images to a connected site's media library (WordPress) or files (Shopify): images from this conversation (generated here or attached by the user) as images, or one image from a public address as url; a client that cannot pass files may send one small image as data_base64. jpeg, png, gif, webp or avif, up to 15 MB each, up to 10 a call, with alt text and title. On WordPress the answer has each media id to use as featured_media or inside content; on Shopify put an image on a product with content_save add_image (its file address), on a blog post with image_url. Allowed in drafts-only mode: an image in the library shows nowhere until something uses it.

Input Schema

NameRequiredDescriptionDefault
urlNoPublic address of one image.
siteNoThe connected site, by its name or address (see connected_sites). Optional when one site is connected.
titleNo
imagesNoImages from this conversation, as files.
alt_textNoAlt text for every image of the call, unless alt_texts gives one each.
filenameNoA name for the url or base64 image, like lavender-candle.png.
alt_textsNoOne alt text per image, in the order of images.
data_base64NoOne image's bytes in base64, only when files cannot be passed.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changed
    • addedInput schema / properties / alt_text / description
      Added value: +"Alt text for every image of the call, unless alt_texts gives one each."
    • addedInput schema / properties / alt_texts
      Added value: +{
+  "description": "One alt text per image, in the order of images.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
    • addedInput schema / properties / data_base64
      Added value: +{
+  "description": "One image's bytes in base64, only when files cannot be passed.",
+  "type": "string"
+}
    • addedInput schema / properties / filename / description
      Added value: +"A name for the url or base64 image, like lavender-candle.png."
    • addedInput schema / properties / images
      Added value: +{
+  "description": "Images from this conversation, as files.",
+  "items": {
+    "additionalProperties": false,
+    "properties": {
+      "download_url": {
+        "type": "string"
+      },
+      "file_id": {
+        "type": "string"
+      },
+      "file_name": {
+        "type": "string"
+      },
+      "mime_type": {
+        "type": "string"
+      }
+    },
+    "required": [
+      "download_url",
+      "file_id"
+    ],
+    "type": "object"
+  },
+  "maxItems": 10,
+  "minItems": 1,
+  "type": "array"
+}
    • changedInput schema / properties / url / description
      Previous value: -"Public address of the image."New value: +"Public address of one image."
    • removedInput schema / required
      Removed value: -[
-  "url"
-]
  2. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Beyond the annotations (which only say non-read-only, open-world, non-idempotent, non-destructive) the description adds hard limits — accepted formats jpeg/png/gif/webp/avif, 15 MB each, up to 10 per call — the WordPress return shape (media ids for featured_media or inline content), and the drafts-only caveat that an unused image is invisible. It does not cover permission/auth requirements or failure behavior, so it is strong but not exhaustive.

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?

The purpose and the input-mode choice are front-loaded in the first clause, and every later clause carries operational information (formats, limits, platform-specific follow-up, drafts mode). It is dense — semicolon-chained — and could be broken into a short bullet list for scanability, but nothing is filler.

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 an 8-parameter mutation tool with no output schema, it supplies the missing pieces: accepted formats and size/count limits, which parameter feeds which kind of image, what the response yields on WordPress, and how the result is consumed downstream. Only failure modes and duplicate handling are unaddressed.

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 already 88%, so the baseline is 3; the description nonetheless clarifies intent the schema leaves open — that `images` and `url` are mutually exclusive in spirit (one image via url), and that `data_base64` is a constrained fallback for one small image. It also implies alt_text/alt_texts/title are applied at upload time, matching the schema's per-call alt-text rule.

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 description gives a specific verb (add/upload) and resource (images to a site's media library / files) and names the two platforms (WordPress, Shopify) whose behavior differs. It is clearly distinguishable from siblings like content_save (which attaches media) or convert_images (which transforms it).

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?

It explicitly routes between the three input modes (conversation `images`, public `url`, `data_base64` as a fallback for clients that cannot pass files) and states what to do next on each platform (content_save add_image / image_url). It also notes drafts-only mode is permitted. It stops short of naming when NOT to use it (e.g. format conversion via convert_images).

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

All AskYourStack 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