Skip to main content
Glama
Sign In

rust.wiki

by wiki.rust
OverviewDiscussionsAdmin

Expected loot from a run of crates, barrels and NPCs

simulate_loot_run
Read-onlyIdempotent

Expected loot from a run of crates, barrels and NPCs. The loot simulator page's exact statistics (https://rust.wiki/calculators/loot-simulator): every item each container can drop is rolled on its own chance, with an amount between the table's min and max. For the whole run, each item gets expected_amount (average total), chance_at_least_one and best_chance_per_container; expected_item_stacks is how many item stacks the run gives on average. Chances come from the game's loot tables (the /loot-tables data). Random opens are done on the page. Loot source names/ids come from list_loot_sources.

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": {
      "run": "<run>"
    },
    "name": "simulate_loot_run"
  }
}

Input Schema

NameRequiredDescriptionDefault
runYesComma-separated `source:count` pairs - a loot source by id (from /loot-tables) or name - count defaults to 1, max 500 each.
limitNoMost items to return (by expected amount).
searchNoOnly items whose name contains this.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely useful behavior beyond that: results are deterministic expected values, not rolls, and random opens happen on the web page rather than in this tool — a distinction that prevents misuse.

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 expands into return metrics and data provenance without much filler. The embedded URL and backticked field names are dense but each carries information; nothing reads as padding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/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 must characterize the return value and does: expected_amount, chance_at_least_one, best_chance_per_container and expected_item_stacks are all explained. Filtering parameters are left to the schema, which is sufficient; only the ordering/pagination behavior of `limit` is unstated by the description.

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 coverage is 100%, so run, limit and search are already documented in the schema, including the `source:count` syntax and the count-defaults-to-1/max-500 rule. The description only adds provenance for source ids (/loot-tables, list_loot_sources), which is a small marginal gain over the structured data.

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?

Names a specific computation and resource: expected loot for a run of crates, barrels and NPCs, with the exact per-item metrics returned. It distinguishes itself implicitly from the raw-table sibling by pointing at /loot-tables data and list_loot_sources for IDs, though no sibling is named as an explicit alternative to this aggregator.

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 implied rather than stated: you feed it a run and get expectations, and the description tells you where to source valid names/ids (list_loot_sources). There is no explicit when-to-use-this-instead-of-get_loot_table or plan_loot_room guidance, so the agent must infer the boundary.

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