rust.wiki

Overlay skins, baskets and indices on one date axis

compare_market

Read-onlyIdempotent

Overlay skins, baskets and indices on one date axis. The data behind rust.wiki/skins/compare: one shared dates axis and a series entry per token with key, name, icon_url, is_basket, is_index and prices aligned to the axis (null where that entry has no data yet). Skin and basket entries are prices in cents (a basket is the plain average of its members' prices); index entries are index levels rebased to 100. Spans over two years are downsampled to weekly points. Cached for 24 hours per parameter combination.

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": {
      "entries": "<entries>"
    },
    "name": "compare_market"
  }
}

Input Schema

Name	Required	Description	Default
`range`	No	Window: `7d`, `30d`, `90d`, `1y`, `2y`, `3y`, `4y`, `5y`, `all`, or `custom` with `start_date`/`end_date`. Spans over two years are downsampled to one point per week.	90d
`smooth`	No	Apply a trailing 30-day moving average.
`entries`	Yes	Comma-separated, up to 8: an `itemdefid` (that skin's price), `category:weapon` / `collection:Forest Raiders` / `item:shoes.boots` (the basket's average price) or `index:all` / `index:category:weapon` / `index:custom:123.456` (an index entry; custom ids joined with `.`).
`end_date`	No	Custom range end (YYYY-MM-DD, inclusive). Only read when range=custom.
`trim_days`	No	Mask each constituent's first N days of history (0-90) to drop launch-week volatility.
`start_date`	No	Custom range start (YYYY-MM-DD, inclusive). Only read when range=custom.
`index_weight_mode`	No	Weighting for any `index:` entries (see /market/index).	equal

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 25, 2026

TDQS

A4/5.0

Behavior5/5

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

Annotations already cover readOnly/idempotent/non-destructive, and the description adds materially more: results are cached 24 hours per parameter combination, spans over two years are downsampled to weekly points, missing points are null rather than omitted, and values are in cents for skins/baskets versus index levels rebased to 100. These are exactly the operational facts an agent needs to interpret a response correctly.

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?

Front-loaded with the purpose, then the response shape, then units and behavioral caveats — a sensible order. A few clauses duplicate the schema verbatim (downsampling over two years, entry syntax), which is mild redundancy in an otherwise dense, waste-free description.

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 no output schema, the description carries the full burden of describing the return shape, and it does: a shared `dates` axis plus per-series `key`/`name`/`icon_url`/`is_basket`/`is_index`/`prices`, including null semantics. Combined with units, downsampling and caching notes, an agent has everything needed to call and interpret it.

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 parameter is already documented in-schema, including the entry syntax and the downsampling note. The description largely restates the entries format and range downsampling; its only added value is explaining that basket entries are a plain average of member prices and that index entries are rebased to 100, which is a modest increment over the schema.

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 gives a specific verb and resource ('Overlay skins, baskets and indices on one date axis') and the description immediately clarifies that this is the multi-series comparison endpoint, distinguishing it from single-series siblings like get_skin_price_history or get_market_index. It stops short of naming an alternative explicitly, but the multi-entry scope is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied: the tool is 'the data behind rust.wiki/skins/compare', and the entries param allows up to 8 mixed tokens, which signals comparison. There is no explicit statement of when to prefer this over get_skin_price_history / get_market_index, nor any exclusion or prerequisite.

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

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