Iminify

Create an upload link

create_upload_link

Get a one-time address to send a local file to, for an agent that can run a shell. PUT the file's bytes to upload_url (the answer includes a curl command), then call compress_images with the upload_id. The link expires after a few minutes and works once; the uploaded file keeps for about a day. Ask for one link per file.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`file_name`	Yes	The file's name, like "hero.png". It names the image; the extension is corrected to what the bytes turn out to be.

Output Schema

TableJSON Schema

Name	Required	Description
`curl`	No	A command that sends the file.
`next`	No
`method`	No
`upload_id`	No	The id to pass to compress_images in upload_ids once the file is sent.
`expires_at`	No
`upload_url`	No
`max_file_size`	No	Bytes.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 24, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "curl": {
+      "description": "A command that sends the file.",
+      "type": "string"
+    },
+    "expires_at": {
+      "type": "string"
+    },
+    "max_file_size": {
+      "description": "Bytes.",
+      "type": "integer"
+    },
+    "method": {
+      "enum": [
+        "PUT"
+      ],
+      "type": "string"
+    },
+    "next": {
+      "type": "string"
+    },
+    "upload_id": {
+      "description": "The id to pass to compress_images in upload_ids once the file is sent.",
+      "type": "string"
+    },
+    "upload_url": {
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

First observedSep 24, 2026

TDQS

A4.4/5.0

Behavior4/5

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

The description discloses key behavioral traits beyond the annotations: the link expires after a few minutes, works once, and the uploaded file keeps for about a day. It also notes the answer includes a curl command. These details are not present in the annotations (which only say readOnlyHint=false), so the description adds valuable context about state and limitations. It does not contradict the 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 concise (two sentences) and front-loaded with the core purpose. It efficiently packs the workflow, constraints, and retention details without fluff. Every sentence contributes essential information, and the structure leads with the main action followed by practical steps.

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?

Given the tool has an output schema (not shown but referenced via upload_url and upload_id) and one required parameter, the description covers the necessary steps to use it: getting a link, putting bytes, and then calling compress_images. It also mentions the expiration and retention. It doesn't address potential failure modes or size limits, but for a straightforward upload tool this is sufficient. The description is complete enough for an agent to act correctly.

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?

The schema covers the single parameter (file_name) at 100% with a description, but the description adds extra meaning: 'the extension is corrected to what the bytes turn out to be' and 'It names the image'. This clarifies that file_name is a label rather than a strict filename, adding nuance beyond the schema. Since schema coverage is high and the description enhances understanding, this is solid.

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 clearly states the tool's purpose: 'Get a one-time address to send a local file to'. It identifies the specific verb (get) and resource (upload link) and distinguishes it from siblings by focusing on the upload workflow. It also adds context about being for an agent that can run a shell, making its role unambiguous.

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?

The description provides clear context for when to use this tool: it's for uploading files, and it gives a follow-up step ('then call compress_images with the upload_id'). It implies the workflow (PUT to upload_url, then compress) and states 'Ask for one link per file'. However, it doesn't explicitly mention when not to use it or compare with alternative upload-related siblings like create_zip or share_image, so it lacks explicit exclusions.

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

All Iminify 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?