kie-mcp

upload_file

Upload local files, URLs, or base64 data to get a public URL for using in AI generation tools (image, video, audio). Files stored for 3 days.

Instructions

Upload a file to kie.ai and get a public URL back. 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.8/5.0

Behavior4/5

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

No annotations are present, so the description carries the full burden. It discloses the 3-day expiration of files, the reliability of file_path over base64_data, the truncation issue with base64_data, and the requirement for publicly reachable URLs. It does not mention potential failure modes or permissions, but for a simple upload tool it covers key behavioral traits well.

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 purpose. It packs critical usage guidance and behavioral notes without redundancy. Every sentence adds value, and the structure effectively guides the agent.

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?

For a tool with 5 parameters and no output schema, the description covers all necessary aspects: what it does, when to use it, how to use each parameter, and key limitations. The mention of returning a public URL sufficiently covers the output, so no additional return details are needed.

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

Parameters5/5

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

With 100% schema coverage, the baseline is 3, but the description goes beyond schema by explaining the trade-offs between file_path, base64_data, and file_url, including when to prefer each and the truncation threshold. It also clarifies that file_path is read by the server itself, adding practical value.

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?

Description clearly states the action (upload file to kie.ai), the result (public URL), and the context (before generation tools). It distinguishes from sibling generation tools by framing it as a preparation step, and mentions specific use cases like image-to-image and video generation.

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?

Explicitly provides usage guidance: 'Use this to upload local images/audio/video before passing them to generation tools' and 'PREFER file_path for local files'. It also clarifies when to use file_url vs file_path vs base64_data, including the warning about base64_data truncation, making it clear when to use alternatives.

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