Skip to main content
Glama
Sign In

rust.wiki

by wiki.rust
OverviewDiscussionsAdmin

Render a Skin Lab outfit, gun or item as an image (WebP/PNG)

skinlab_render_outfit
Read-onlyIdempotent

Render a Skin Lab outfit, gun or item as an image (WebP/PNG). Returns {status: "done", url, cached, width, height, format} with a permanent image URL (same request = same URL; images are cached), plus outfit (the normalised pieces, their Steam prices and total_price in USD cents, and any clashes / invalid attachments dropped exactly as /skin-lab/outfit reports them), viewer_url (the same outfit in the interactive 3D viewer) and render_quota. A render that takes longer than wait seconds answers 202 {status: "queued", position, retry_after} - call again with the same parameters (no extra quota) after Retry-After seconds. 429 when the render queue is full or a quota is used up. New images count against a separate render quota (100 per key per UTC day); cached images don't. Use when someone wants to SEE an outfit, skin, gun or item: returns the rendered image inline (you can look at it and show it) plus a permanent image URL, the interactive 3D viewer link, the outfit's pieces and total Steam price. pieces uses the same format as skinlab_build_outfit (find skins with search_skins / skinlab_get_item); a gun with attachments in item view = mode weapon. Rendering a new image takes a few seconds; if it says pending, call again with the same arguments. Keyless use shares a small daily render budget.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "skinlab_render_outfit"
  }
}

Input Schema

NameRequiredDescriptionDefault
yawNoTurn the character/item, degrees.
bodyNoBody model.male
faceNoFace (head) name for that body, e.g. `Frank` (default: the first face).
modeNo`outfit` (on the player), `weapon` (the FIRST piece on its own - guns, tools, deployables) or `pov` (first person; needs a gun or tool).outfit
poseNoPose key, e.g. `idle`, `wave`, `crouch`, `rifle_aim` (default `auto`). Moving poses are shown frozen.
zoomNoCamera zoom (1 = the viewer's framing).
lightNoLighting: studio, day, golden, overcast, dusk, night. `studio` on an in-game scene = that scene's own daylight.studio
widthNoImage width, px.
formatNo`webp` (small) or `png`.webp
heightNoImage height, px.
piecesNoThe outfit, exactly as for /skin-lab/outfit: comma-separated `item[:skin[:attachment~attachment]]` (item by shortname or name, skin by itemdefid or name, attachments for guns; a bare number is a skin itemdefid). Left out = the viewer's starter outfit.
weatherNoIn-game scenes only: auto, off, clear, cloudy, fog, rain, storm, snow.auto
backgroundNo`studio`, `dark`, `light`, `sky`, `sunset`, or an in-game scene: plains, forest, arctic, desert, beach, set_base, set_garage, set_compound, set_monument, set_launch, set_market, set_military, set_dock, set_coast.studio
transparentNoTransparent backdrop (studio-type backgrounds only; the floor disc stays).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.4/5.0
Behavior5/5

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

Goes well beyond the readOnly/idempotent annotations: permanent URL + cache semantics, the 202 queued flow with Retry-After and the instruction to re-call with identical args at no extra quota, 429 conditions, and a 100-per-key-per-day render quota with a shared keyless budget. It also sets expectations that a render takes a few seconds.

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?

Dense and largely front-loaded on what is returned, which is the operational core. There is some redundancy — the retry-with-same-arguments instruction appears twice (once for the 202 path, once in the closing sentence) — and the opening sentence restates the title, but the payload is informative rather than padded.

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?

With 14 optional parameters and no output schema, the description carries the full burden of explaining the return shape, and it does: status/url/cached/width/height/format, the normalised `outfit` with prices in USD cents and clash reporting, `viewer_url`, and `render_quota`. An agent has everything needed to call it and interpret both success and queued responses.

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 every one of the 14 parameters is already documented in the schema, and the description mostly paraphrases that. The one genuine addition is the cross-reference that `pieces` uses the same format as skinlab_build_outfit and that skins are found via search_skins / skinlab_get_item, which is useful discovery context but limited.

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?

States a specific verb (render) and resource (Skin Lab outfit, gun or item) plus the output format (WebP/PNG). It is clearly distinguishable from skinlab_build_outfit, which it references as the source of the `pieces` format, so an agent can tell viewing/rendering apart from building.

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?

Explicitly says to use it 'when someone wants to SEE an outfit, skin, gun or item' and explains the mode choice (a gun with attachments in item view = mode `weapon`). It also points to search_skins / skinlab_get_item for discovering pieces. It stops short of stating when not to use it (e.g. text-only price questions), so not a 5.

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

All rust.wiki toolsInspect
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