Skip to main content
Glama
Sign In

rust.wiki

by wiki.rust
OverviewDiscussionsAdmin

Build and check a Skin Lab outfit: wear-rule clashes, attachments, total price and the 3D link

skinlab_build_outfit
Read-onlyIdempotent

Build and check a Skin Lab outfit: wear-rule clashes, attachments, total price and the 3D link. Puts the pieces on in order, the way the viewer and the game do. Pieces that can't be worn together (the game's own wear rules: two pieces clash when they occupy the same under-layer or over-layer body area - a Coffee Can Helmet and a Metal Facemask both cover the head) are reported in clashes with the piece they conflict with and why; the first piece wins and the later one is left out of the link, exactly as the viewer would; a second piece for a viewer slot that's already filled is a clash too. invalid_attachments lists attachments a gun doesn't accept or that fight for the same attachment slot; errors lists pieces that couldn't be resolved (unknown item, or a skin that isn't in 3D yet). slots is the normalised outfit (slot, item, skin, price), total_price the sum of the chosen skins' Steam lowest listings in USD cents (default looks cost nothing; unpriced counts skins with no listing), valid is true when nothing was dropped, and viewer_url opens the outfit in rust.wiki/skin-lab. Use to put together or check a whole Rust outfit (e.g. 'hoodie with the Tempered skin, metal facemask, AK with a holosight'): it applies the game's wear rules, flags pieces that can't be worn together and why, checks gun attachments, totals the skins' Steam price, and returns a viewer_url showing the outfit in 3D. Find skin itemdefids with search_skins or skinlab_get_item.

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": {
      "pieces": "<pieces>"
    },
    "name": "skinlab_build_outfit"
  }
}

Input Schema

NameRequiredDescriptionDefault
bodyNoBody model.male
faceNoFace (head) name for that body, e.g. `Frank` - list in the error when wrong.
modeNoViewer mode for the link: `outfit`, `weapon` (the first piece on its own) or `pov` (first person; needs a gun or tool).outfit
poseNoPose key, e.g. `idle`, `wave`, `crouch`, `rifle_aim`, `walk` (default `auto`). Invalid keys are listed in the error.
piecesYesComma-separated pieces, each `item[:skin[:attachment~attachment]]` - item by shortname or name, skin by itemdefid or name (left out or 0 = default look), attachments for guns. A bare number is a skin itemdefid. Up to 14 pieces, one per viewer slot.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.5/5.0
Behavior5/5

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

Annotations only declare read-only/idempotent safety, and the description adds far more: the exact clash rule (same under- or over-layer body area), the first-piece-wins ordering that drops the later piece from the link, slot-collision clashes, attachment-slot conflicts, and the pricing basis (Steam lowest listing, USD cents, defaults free, `unpriced` counter). This is precisely the beyond-annotations context the agent needs to interpret the result rather than treat it as a black box.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The middle is dense but informative; the problem is the closing sentence, which restates the purpose already established ('applies the game's wear rules, flags pieces that can't be worn together and why, checks gun attachments, totals the skins' Steam price, and returns a viewer_url') almost verbatim. Nested parentheticals like the Coffee Can Helmet example also push the reading order well past the front-loaded claim.

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?

There is no output schema, and the description compensates by documenting every result key: `clashes`, `invalid_attachments`, `errors`, `slots`, `total_price`, `unpriced`, `valid`, `viewer_url`. For a five-parameter, multi-rule aggregation tool, nothing an agent needs in order to call it or read the response is missing.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description genuinely adds meaning the schema does not state: that `pieces` is applied 'in order, the way the viewer and the game do' and that ordering determines which clashing piece survives. The remaining parameters (body, face, pose, mode) are left to the schema, which documents them fully.

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 opens with a specific verb+resource ('Build and check a Skin Lab outfit') and immediately enumerates exactly what is checked: wear-rule clashes, attachments, total price, 3D link. The closing sentence names the prerequisite siblings ('Find skin itemdefids with search_skins or skinlab_get_item'), so an agent can place it in the workflow without opening any schema.

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 states the intended use explicitly ('Use to put together or check a whole Rust outfit') with a concrete example input, and routes the agent to search_skins / skinlab_get_item for the itemdefids the `pieces` parameter needs. There is no explicit when-not or comparison against the nearby skinlab_link / skinlab_render_outfit siblings, which keeps it short of 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