MascotLab

Download an artifact

download_artifact

Read-onlyIdempotent

Mints a fresh download URL (valid 10 minutes) for any artifact on the board: mascot, prop, pose (PNG) or animation (MP4). Use the ids from get_board, and fetch the URL promptly, for example with curl, to save the file into the repository. Pass background:"none" for a transparent PNG, which is usually what you want when placing a mascot onto an app screen. The first transparent request for an artifact takes a few seconds while the cutout is made; every request after it is instant, so wait rather than retry.

Input Schema

Name	Required	Description	Default
`id`	Yes	The artifact id from get_board.
`kind`	Yes	What the id refers to: mascot, prop, pose or animation. Use the same kind the id came from in get_board.
`background`	No	Which copy to download. "original" keeps the backdrop the artwork was drawn on. "none" returns a transparent PNG with the subject cut out, which is what you want for placing a mascot onto a screen. Not available for animations, since MP4 cannot carry an alpha channel.	original

Output Schema

Name	Required	Description	Default
`id`	No
`ok`	Yes
`kind`	No
`filename`	Yes
`background`	Yes
`content_type`	No
`download_url`	Yes
`download_hint`	No
`expires_in_seconds`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 23, 2026

addedInput schema / properties / background

Added value: +{
+  "default": "original",
+  "description": "Which copy to download. \"original\" keeps the backdrop the artwork was drawn on. \"none\" returns a transparent PNG with the subject cut out, which is what you want for placing a mascot onto a screen. Not available for animations, since MP4 cannot carry an alpha channel.",
+  "enum": [
+    "original",
+    "none"
+  ],
+  "type": "string"
+}

addedOutput schema / properties / background
```
Added value: +{
+  "type": "string"
+}
```

changedOutput schema / required

Previous value: -[
-  "ok",
-  "download_url",
-  "filename"
-]New value: +[
+  "ok",
+  "download_url",
+  "filename",
+  "background"
+]

First observedAug 5, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Beyond the annotations, the description discloses the 10-minute URL lifetime, the first-transparent-request cutout delay, subsequent instant requests, and a concrete wait-rather-than-retry instruction. These are meaningful behavioral details for an agent invoking the tool.

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 front-loaded with the core action and URL expiration, then moves through usage, background selection, and latency guidance. Every sentence contributes useful information with no repetition or filler.

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 download tool with rich schema coverage and an output schema, the description covers the essential invocation context: URL expiry, fetching promptly, transparent PNG behavior, and first-request latency. Nothing critical is missing for an agent to call it correctly.

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 explains id, kind, and background thoroughly. The description mostly restates those parameter meanings and adds a latency note that is behavioral rather than parameter-specific, so the baseline 3 is appropriate.

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: minting a fresh download URL for an artifact on the board, and it enumerates the artifact kinds. It also points to get_board as the source of ids, which implicitly distinguishes it from the create_* siblings.

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 clear operational guidance: use ids from get_board, fetch the URL promptly, and use background:none for transparent PNGs when placing a mascot on an app screen. It does not explicitly state when not to use the tool or name alternatives, but the usage context is otherwise clear.

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

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