Kalpana Batch

Add the user's images

upload_images

Idempotent

Brings the user's own images (PNG, JPEG, or WebP, up to 5 MB each) into the workspace, optionally into a collection, which is made when no collection has that name. Without files it returns a link to the workspace's Images page (the collection's page with collection) for the user to drop the images into; after they say they are done, search_assets finds them. Images already online, such as product photos from a store, go in urls: Kalpana fetches each one (up to 20 a call, 5 MB each) and returns it recorded, with no upload step; a URL's host has to be on the workspace's domain whitelist (cdn.shopify.com is on it by default, and an admin adds others in Workspace Settings), and a URL that fails is listed in failed while the rest are stored, with a link to the settings page when its host is not whitelisted. An agent that has the files (a shell, files on disk) works in three steps: call with files (each one's SHA-256 hash, content type and size) to get one uploadUrl per file; PUT each file's bytes to its uploadUrl with that Content-Type header; then call again with done (each hash and file name) to record them. The recorded images come back with their id, the asset_id of an image input in batch rows. Image data is not accepted inline as base64. To look at an image already uploaded use inspect_image, and to find one search_assets. Needs assets:create.

Input Schema

Name	Required	Description
`done`	No	Files you uploaded, to record them
`urls`	No	Images for Kalpana to fetch from the web, instead of files and done
`files`	No	Files you will upload yourself
`collection`	No	Collection to put the images in, by name

Output Schema

Name	Required	Description
`link`	No	The workspace's Images page for the user
`step`	Yes	link: give the user the link; uploads: PUT each file, then call with done; done: the images are recorded
`failed`	No
`images`	No
`uploads`	No
`collection`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedOct 30, 2026
- removedInput schema / additionalProperties
```
Removed value: -false
```
- removedInput schema / properties / done / items / additionalProperties
```
Removed value: -false
```
- removedInput schema / properties / files / items / additionalProperties
```
Removed value: -false
```
- removedInput schema / properties / urls / items / additionalProperties
```
Removed value: -false
```
- addedOutput schema / properties / images / items / properties / height / maximum
```
Added value: +9007199254740991
```
- addedOutput schema / properties / images / items / properties / id / pattern
```
Added value: +"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12})$"
```
- addedOutput schema / properties / images / items / properties / width / maximum
```
Added value: +9007199254740991
```

Changed3 schema fields changedOct 24, 2026

addedInput schema / properties / urls

Added value: +{
+  "description": "Images for Kalpana to fetch from the web, instead of files and done",
+  "items": {
+    "additionalProperties": false,
+    "properties": {
+      "name": {
+        "description": "File name; defaults to the URL's last segment",
+        "maxLength": 200,
+        "minLength": 1,
+        "type": "string"
+      },
+      "url": {
+        "description": "A public image URL on the workspace's whitelist",
+        "format": "uri",
+        "type": "string"
+      }
+    },
+    "required": [
+      "url"
+    ],
+    "type": "object"
+  },
+  "maxItems": 20,
+  "minItems": 1,
+  "type": "array"
+}

addedOutput schema / properties / failed / items / properties / url
```
Added value: +{
+  "type": "string"
+}
```

changedOutput schema / properties / failed / items / required

Previous value: -[
-  "contentHash",
-  "message"
-]New value: +[
+  "message"
+]

First observedOct 22, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare the write/idempotent/open-world profile, but the description adds substantial behavior beyond them: per-file and per-call size/format limits, domain-whitelist requirements with the default cdn.shopify.com entry, partial-failure semantics ('a URL that fails is listed in failed while the rest are stored'), the settings-page link on whitelist failure, and the recorded-image return including id and asset_id. It also rules out base64 inline data.

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 core purpose is front-loaded and nearly every clause carries operational information (limits, whitelist, partial failure, permission). However, it is delivered as one dense run-on paragraph with nested asides such as the Shopify example, which makes the three-step flow harder to scan than a short ordered list would be.

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?

An output schema exists, so return values need not be spelled out, and everything else an agent needs for this multi-modal, two-phase upload is present: formats, size caps, whitelist behavior, failure handling, the sequential PUT step, and the mandate to use inspect_image/search_assets afterward.

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 3, but the description adds cross-parameter meaning the schema cannot express: the files → PUT → done sequencing, the requirement that done carries each hash plus file name, that collection is auto-created when no name matches, and that urls fetches at most 20 per call. Slight deduction only because per-field details like the sha256 hex format and name defaulting are left to the schema.

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 states a specific verb and resource ('brings the user's own images ... into the workspace') and enumerates all three intake modes: local files via the two-step files/done flow, remote images via urls, and the no-argument link fallback. It explicitly routes the agent away from inspect_image and search_assets for viewing and finding, so the tool is distinguishable from its siblings without opening a schema.

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?

Each mode carries an explicit when-to-use rule: images already online go in urls, an agent holding files follows the three-step upload, and a bare call returns a drop page for the user. It also names the alternatives for other intents ('To look at an image already uploaded use inspect_image, and to find one search_assets') and states the assets:create prerequisite.

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

All Kalpana Batch tools Inspect

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

Need Help?