kie-mcp

upload_file

Upload local images, audio, or video to kie.ai to get a public URL for generation tools. Corrects file extensions using magic bytes to prevent rejection.

Instructions

Upload a file to kie.ai and get a public URL back. Image files are named by their REAL format (magic bytes), so a JPEG saved as .png is uploaded as .jpg — kie serves files with a Content-Type taken from the name, and Veo I2V rejects a mismatch. Use this to upload local images/audio/video before passing them to generation tools (image-to-image, image-to-video, reference/ingredient inputs). PREFER file_path for local files. Files expire after 3 days (kie temp storage).

Input Schema

TableJSON Schema

Name	Required	Description	Default
`file_url`	No	URL of file to upload — must be PUBLICLY reachable by kie.ai servers (no localhost/private IPs, no auth-gated or expired links). For local files use file_path
`file_name`	No	Custom filename (optional)
`file_path`	No	Absolute path to a local file on the machine running this MCP server (the normal case for stdio setups). The server reads and streams the bytes itself — reliable at any size, unlike base64_data. PREFERRED for local files.
`base64_data`	No	Base64-encoded file data — raw base64 or a full data: URI. Whitespace and base64url are normalized and the data:<mime>;base64, prefix is stripped automatically (its MIME infers the extension if file_name is omitted). WARNING: payloads above ~10-12K chars (observed ceiling ~11.7K, #68) are silently truncated in transit as a tool argument — use file_path for local files; base64_data is a fallback for remote/HTTP-mode callers with small payloads.
`upload_path`	No	Storage directory (e.g. "images", "audio", "video")	uploads

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv4.8.0Aug 20, 2026

changedInput schema / properties / base64_data / description

Previous value: -"Base64-encoded file data — raw base64 or a full data: URI. Whitespace and base64url are normalized and the data:<mime>;base64, prefix is stripped automatically (its MIME infers the extension if file_name is omitted). NOTE: very large images can be truncated when passed as a tool argument — if you get a length/invalid error, prefer file_url with a public URL."New value: +"Base64-encoded file data — raw base64 or a full data: URI. Whitespace and base64url are normalized and the data:<mime>;base64, prefix is stripped automatically (its MIME infers the extension if file_name is omitted). WARNING: payloads above ~10-12K chars (observed ceiling ~11.7K, #68) are silently truncated in transit as a tool argument — use file_path for local files; base64_data is a fallback for remote/HTTP-mode callers with small payloads."

addedInput schema / properties / file_path

Added value: +{
+  "description": "Absolute path to a local file on the machine running this MCP server (the normal case for stdio setups). The server reads and streams the bytes itself — reliable at any size, unlike base64_data. PREFERRED for local files.",
+  "type": "string"
+}

changedInput schema / properties / file_url / description

Previous value: -"URL of file to upload — must be PUBLICLY reachable by kie.ai servers (no localhost/private IPs, no auth-gated or expired links). For local files use base64_data"New value: +"URL of file to upload — must be PUBLICLY reachable by kie.ai servers (no localhost/private IPs, no auth-gated or expired links). For local files use file_path"

First observedv4.7.0Jul 28, 2026

TDQS

A4.4/5.0

Behavior5/5

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

With no annotations, the description carries the full burden and discloses important behavior: files expire after 3 days, image files are named by real magic-byte format rather than extension, Content-Type follows the name, and Veo I2V rejects mismatches. This is rich operational context beyond the schema.

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 description is front-loaded with purpose and stays dense without obvious filler. It is slightly run-on and could be structured more clearly, but every sentence contributes relevant information.

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?

Given no output schema and no annotations, the description covers what matters for correct invocation: return value, expiry behavior, naming/Content-Type caveats, intended usage, and parameter preference. The fully documented schema covers the remaining parameter details.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents every parameter in detail. The description only restates the preference for file_path over other input methods, adding little meaning beyond what the schema provides.

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: upload a file to kie.ai and get a public URL back. It distinguishes itself from generation siblings by framing itself as a preparatory upload utility used before passing files to generation tools.

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 clearly says to use this before passing local images/audio/video to generation tools and explicitly prefers file_path for local files, which routes the agent among input parameters. It does not mention when not to use it or name a sibling upload alternative such as upload_extend_audio.

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

upload_file

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools