Tailwind App

create_media_upload

Use this when the user wants to Pin their own image or video file: a Canva export, a photo or video on disk, anything without a publicly accessible URL. Creates a single-use upload in Tailwind's media staging and returns its uploadId, a write-only uploadUrl, the contentType that uploadUrl accepts, and two expiry times: one for uploadUrl and a later one for uploadId. The tool has two modes. With file, an attachment object that the host application supplies for a file the user attached, the server downloads the attachment and stages its bytes during the call, so the returned uploadId already refers to the staged media. Hosts that do not supply attachment objects leave file out and use the extension mode. With only extension, nothing is staged yet: the bytes are staged when they are sent to uploadUrl in an HTTP PUT whose Content-Type equals contentType. create_post accepts the uploadId as its uploadId input, in place of mediaUrl. Each uploadId attaches to exactly one Pin. Creating an upload costs no credits. Not for media that already has a public URL, which create_post takes directly as mediaUrl.

Input Schema

Name	Required	Description	Default
`file`	No	An attachment object for a file the user attached, filled in by the host application. Only the host can supply it: an object you construct yourself, or a file path, is not a valid value. If the host does not provide one, omit this and use `extension` with uploadUrl. When it is present the server downloads the file and stages its bytes during the call, so no PUT to uploadUrl is involved.
`extension`	Yes	The file's extension, with or without a leading dot and in any case (jpg, .PNG, mp4). It determines both the upload's media type and the Content-Type the signed URL is issued for. Accepted: jpg, jpeg, png, svg, gif, webp, heic, mp4, mov, qt. When `file` is also present its mime_type/file_name take precedence, so a wrong guess here is not fatal.

Output Schema

Name	Required	Description	Default
`upload`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 21, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Beyond the annotations (readOnlyHint=false, idempotentHint=false, openWorldHint=true), it discloses that the upload is single-use, that uploadId binds to exactly one Pin, that expiry windows differ for uploadUrl vs uploadId, that the URL is write-only, and that creating an upload costs no credits. It also explains the two internal modes and exactly when a PUT is or is not required.

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 critical routing information (when to use, when not, alternative) is front-loaded, and the mode explanation follows logically. It runs long for a two-parameter tool, and restating the return payload slightly duplicates the output schema, but most sentences carry operational weight.

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 agent has everything needed to call it correctly and to chain into create_post, and the two-mode branching (host attachment vs. extension + PUT) is fully spelled out. With an output schema present, the description need not explain returns, yet it adds useful framing about expiry ordering.

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 100%, but the description adds the mode-level framing: `file` is host-supplied only and triggers server-side download during the call, while `extension` alone stages nothing until an HTTP PUT with the matching Content-Type. That is real semantic value, though some of it duplicates the schema's own text about omitting `file` and using `extension`.

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 opens with a specific verb and resource — creating a single-use media upload in Tailwind's staging — and immediately scopes it to user-owned files without a public URL. It explicitly contrasts with create_post/mediaUrl, so an agent can distinguish it from siblings without opening any 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?

It gives concrete when-to-use examples (Canva export, photo or video on disk) and an explicit when-not: media with a public URL should go to create_post as mediaUrl. It even tells the agent which sibling consumes the output (create_post's uploadId input), leaving nothing to inference.

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

All Tailwind App 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?