Skip to main content
Glama

Skin market index series

get_market_index
Read-onlyIdempotent

Skin market index series. The rust.wiki Market Index: a basket of skins rebased to 100 at the start of the window, like a stock index, built from Steam's daily price history (one point per day; weekly beyond two years). Returns dates (ISO dates), values (index level, 100 = the window's first day), constituent_count (skins that had a price at the baseline; baskets are capped at 300 constituents) and label. A skin whose history starts inside the window joins from its first price. Cached for 24 hours per parameter combination (history only gains a point every 6 hours); the full catalogue, every category and every collection are kept warm server-side.

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": "get_market_index"
  }
}

Input Schema

NameRequiredDescriptionDefault
rangeNoWindow: `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
smoothNoApply a trailing 30-day moving average.
end_dateNoCustom range end (YYYY-MM-DD, inclusive). Only read when range=custom.
trim_daysNoMask each constituent's first N days of history (0-90) to drop launch-week volatility.
start_dateNoCustom range start (YYYY-MM-DD, inclusive). Only read when range=custom.
basket_typeNoWhich skins form the index: `all`, `high_value`/`low_value` (300 priciest/cheapest), `category`, `collection`, `color`, `item` (one base item's skins) or `custom` (your own list).all
weight_modeNo`equal`: every constituent's % move counts the same. `marketcap`: weighted by price x Workshop subscribers, like an S&P-style index.equal
basket_valueNoThe category, collection name, colour, item shortname, or for `custom` a comma-separated list of up to 300 itemdefids. Ignored for all/high_value/low_value.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.8/5.0
Behavior4/5

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

Beyond the readOnly/idempotent annotations, the description discloses real behavior: 24-hour caching per parameter combination, server-side warm cache across catalogue/category/collection, weekly downsampling beyond two years, and a 300-constituent cap. It also explains a non-obvious edge case — a skin whose history starts inside the window joins from its first price — which materially affects interpretation of the series.

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?

Purpose and the index definition are front-loaded, followed by return fields and caching notes — a sensible order. There is mild redundancy: 'rebased to 100 at the start of the window' is restated as 'values (index level, 100 = the window's first day)'. Dense but nearly every sentence carries information.

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 enumerating the returned fields (dates, values, constituent_count, label) with their semantics. With annotations covering safety, all 8 parameters documented in-schema, and caching/downsampling behavior explained, an agent has everything needed to call and interpret this 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% and the enum values are self-documenting, so the schema already carries the parameter burden. The description reinforces rebasing and the constituent cap but adds no new parameter-level detail (e.g. how smooth interacts with custom ranges, or what 'eligible' means for high_value baskets). Baseline 3 applies.

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?

States a specific verb+resource ('Skin market index series') and defines the artifact precisely: a basket of skins rebased to 100, built from Steam daily prices. An agent can tell this is a composite index rather than a single-skin price series. It never names the adjacent siblings (get_market_cap, get_skin_price_history, compare_market, get_market_movers), so differentiation is inferred rather than stated.

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 stock-index framing suggests aggregate trend tracking, but there is no explicit 'use this when you want X, use get_market_cap / get_skin_price_history when you want Y'. No exclusions or prerequisites are given, leaving the agent to guess among several market-related siblings.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources