Skip to main content
Glama

rust.wiki

Executable buy-on-marketplace, sell-on-Steam flips

find_skin_deals
Read-onlyIdempotent

Executable buy-on-marketplace, sell-on-Steam flips. Every skin that can be bought on a third-party marketplace for less than it nets on Steam Community Market right now, as rust.wiki/skins/deals computes it. Per deal: buy_market and buy_price (the cheapest in-stock listing we poll, cents), sell_url (the Steam listing page), the two Steam references bid_gross/bid_net (highest buy order, and what you actually receive after Steam's 15% fee) and ask_gross/ask_net (lowest sell order, same), then for the chosen steam_ref: sell_price (the net proceeds), sell_gross, spread_abs (cents) and spread_pct. Only rows profitable under the chosen reference are returned. A stale buy order above a fresher ask is capped at the ask. Filters combine with AND; search matches the skin name case-insensitively. Marketplace links are not included. Recomputed every ~5 minutes from the marketplace poll.

Input Schema

NameRequiredDescriptionDefault
pageNo1-based page number.
sortNoBest `pct` (spread as % of buy price) or `abs` (spread in cents) first.pct
searchNoCase-insensitive substring of the skin name (or Steam market name).
categoryNoOnly skins of this category.
per_pageNoResults per page (max 200).
max_priceNoMaximum buy price in cents.
min_priceNoMinimum buy price in cents.
steam_refNoSteam exit price: `buy` = sell instantly into the highest buy order (default), `sell` = list just under the lowest sell order.buy
marketplaceNoOnly deals whose cheapest listing is on one of these marketplaces (repeat the parameter).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare this is a read-only, idempotent, non-destructive tool, and the description adds substantial behavioral detail beyond that: data is recomputed every ~5 minutes, stale buy orders above fresher asks are capped, Steam's 15% fee is reflected in net fields, and marketplace links are omitted.

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?

The first sentence is front-loaded and states the core purpose immediately. The remaining text is dense but justified because no output schema exists and the return fields need documentation, though the long inline field enumeration is heavier than ideal.

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?

Given nine optional parameters, full schema coverage, no output schema, and read-only annotations, the description is complete: it documents the return fields, freshness cadence, fee treatment, profitability filter, stale-order handling, and missing marketplace links.

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 description coverage is 100%, so parameter meanings are already well documented. The description still adds useful semantics around `steam_ref` outcomes, the effect of only returning profitable rows under that reference, and AND-combined filters.

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 precise verb-resource framing: executable buy-on-marketplace, sell-on-Steam flips. It further specifies the exact computation basis and profitability condition, so an agent can distinguish this from general skin pricing or browsing tools.

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?

Usage context is clear: this tool returns only rows profitable under the chosen `steam_ref`, with filters combined by AND. However, it does not explicitly name when to use this instead of siblings such as `get_skin_price` or `get_market_movers`, so it lacks explicit alternatives/exclusions.

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