Kuro

Get download URL

get_download_url

Read-onlyIdempotent

A short-lived attachment URL for a ready generation or verified upload, on this server's own API host. A set (a group: a carousel, a workflow run's pictures) returns one ordered ZIP of its members. Minted at the press; ask again rather than caching it. With as: "image" the picture itself comes back too, as image content the client can save: a clip's poster frame, a set's ready pictures in order (up to ten), nothing for a sound. That is how to put Kuro pictures into a page or an artifact when the sandbox cannot download. If the sandbox refuses that host, ask the user (or whoever manages their workspace) to allow it, and do not try other hosts.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "reference": "<reference>"
    },
    "name": "get_download_url"
  }
}

Input Schema

Name	Required	Description
`as`	No	url (the default) returns the link alone; image also attaches the picture itself as a 1280px WebP.
`filename`	No
`reference`	Yes

Output Schema

Name	Required	Description	Default
`message`	Yes
`download_url`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 28, 2026

addedInput schema / properties / as

Added value: +{
+  "description": "url (the default) returns the link alone; image also attaches the picture itself as a 1280px WebP.",
+  "enum": [
+    "url",
+    "image"
+  ],
+  "type": "string"
+}

First observedOct 15, 2026

TDQS

A4.1/5.0

Behavior5/5

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

Annotations already declare this read-only, idempotent and non-destructive, and the description adds substantial behavior beyond them: URLs are short-lived and must be re-minted, set references collapse to a single ordered ZIP, image mode returns inline image content (poster frame for clips, up to ten set pictures, nothing for sound) at 1280px WebP, and there is an explicit host-allowlist failure path. This is exactly the operational context annotations cannot carry.

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 key facts — what it returns, freshness, and image mode — are front-loaded, and every sentence carries information (set/ZIP behavior, poster frames, host refusal handling). The prose is idiosyncratic ('Minted at the press') and slightly dense, but nothing is redundant filler.

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?

With an output schema present, the description needn't explain return shapes, and it still covers the practical edge cases: short-lived URLs, ZIP ordering for sets, per-type image content, and sandbox host restrictions. The residual gaps are the undocumented `filename` parameter and the lack of any readiness/prerequisite rule for generation references.

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 only 33%, and the description does explain the meaning of `reference` variants (ready generation vs. verified upload vs. a set/group) and elaborates on `as: "image"` beyond the schema's own text. However, `filename` gets no explanation anywhere, and the description never clarifies what makes a generation 'ready' or an upload 'verified' — gaps the schema's bare union types do not fill.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence states a concrete verb and resource: it returns a short-lived attachment URL for a 'ready generation or verified upload' on the server's own API host. It also scopes what a set reference yields (an ordered ZIP), which separates it from link-minting siblings like create_share_link or get_upload_link, though it never names an alternative tool explicitly.

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 gives real when-to-use guidance: use `as: "image"` to embed Kuro pictures into a page or artifact when the sandbox cannot download, and it says to re-request rather than cache because URLs are minted at request time. It also prescribes the fallback when a sandbox blocks the host (ask the user/workspace manager to allow it, don't try other hosts). The only gap is that it never contrasts itself by name with create_share_link or get_upload_link for durable links.

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

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