rust.wiki

What an inventory is realistically worth

get_inventory_valuation

Read-onlyIdempotent

What an inventory is realistically worth. The inventory valued three ways, plus what selling would actually raise. at_asks is the headline number (each skin at its cheapest Steam listing, falling back to the best buy order); at_bids is every skin at its best buy order; at_recent_sales is every skin at its latest Steam median sale price (the inventory chart's basis). sell_now walks each skin's real buy-order ladder for the quantity held: units_sellable of units_held could be sold instantly for gross (what buyers pay) and net_after_fees (after Steam's 15%). biggest_ask_gaps lists the skins whose cheapest listing sits furthest above their recent sales - thin order books where the headline is least reliable. All cents. Uses the stored holdings (the last lookup) and current order books: never a live Steam call; look the inventory up first if found is false. No key needed. Use when asked what an inventory is REALLY worth or would sell for: asks vs bids vs recent sales, and instant-sell proceeds after Steam's 15% fee.

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": {
      "steamid": "<steamid>"
    },
    "name": "get_inventory_valuation"
  }
}

Input Schema

Name	Required	Description	Default
`steamid`	Yes	17-digit SteamID64.

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 25, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Beyond the annotations (readOnly, idempotent, closed-world), it discloses that holdings come from the last lookup, that order books are the live source, that it never makes a live Steam call, that no API key is required, and that all monetary values are in cents. It also flags a reliability caveat — thin order books make the headline number least trustworthy — which is real behavioral context an agent could not infer.

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-loads the headline purpose and then enumerates each output field with a definition, so every sentence earns its place. It is dense and slightly long with awkward line wrapping, but there is no filler or repetition.

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 explaining return values — and it does, defining `at_asks`, `at_bids`, `at_recent_sales`, `sell_now` with `units_sellable`/`units_held`/`gross`/`net_after_fees`, and `biggest_ask_gaps`. Combined with the fee rate, currency unit, and data-freshness caveat, an agent has everything needed to call it and interpret the result.

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?

Only one parameter (`steamid`), and the schema already documents it at 100% coverage (17-digit SteamID64). The description doesn't restate or enrich the parameter, though it implicitly clarifies that the steamid gates whether `found` is true and thus whether a prior lookup is needed. Baseline 3 applies.

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 resource and a precise multi-faceted operation: three valuation bases (`at_asks`, `at_bids`, `at_recent_sales`), an instant-sell simulation (`sell_now`), and a reliability diagnostic (`biggest_ask_gaps`). It also carves out scope against adjacent tools by noting it uses stored holdings and current order books rather than returning the holdings themselves or making a live Steam call.

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 'Use when asked what an inventory is REALLY worth or would sell for' and names the three-way comparison and fee-adjusted proceeds as the trigger. It also gives a prerequisite ('look the inventory up first if `found` is false'), which is actionable guidance. It stops short of naming a specific sibling by name for the alternative path.

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?