Skip to main content
Glama

Get a player's wishlist

get_wishlist
Read-only

Retrieve a player's public Steam wishlist by SteamID64, with optional filters for tags, platform, discount, and compatibility ratings. Get detailed store cards including prices, reviews, and release info in a single call.

Instructions

List a player's Steam wishlist by SteamID64. Works without a key, but only if that player's wishlist/profile is public — otherwise it returns found:false. By default returns a light list of appids (sorted by priority, no names), capped at the first 100 (check returned vs total). Set include_details for full store cards in ONE call (name, price/discount, review %, Deck/SteamOS/Machine/Frame compat, vr_support, tags, release) — no need to follow up with get_items. Narrow it in the SAME call with tags (e.g. ['Metroidvania']), platform (NATIVE windows/mac/linux build), steam_deck / steam_os / steam_machine / steam_frame (Proton compatibility — distinct from a native build), min_review and min_discount / on_sale_only, or country / language (the light appid list carries no price, so setting either implies include_details too) — these are applied before the output cap (the detailed card list returns at most 60 items), so a deeply-discounted niche match past the display cap is never hidden by it (e.g. 'top metroidvanias on my wishlist with a good discount and reviews' → tags:['Metroidvania'] + min_discount + min_review). Results ranked by discount when a discount filter is set, else by wishlist priority; matched reports the pre-cap count. Steam itself only attaches store data to roughly the first 100 wishlist entries per call — on a bigger wishlist, enriched reports how many of total got checked, and note explains when some were skipped (their filter/price data isn't available at all, not that they don't match). Convert a vanity name with resolve_vanity_url first.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tagsNoKeep only wishlist items carrying ALL of these user tags (case-insensitive), e.g. ['Metroidvania']. Use exact Steam tag names — a misspelled/unrecognized one isn't an error, it just matches nothing. Implies include_details.
countryNoCountry (cc) for prices; overrides STEAM_COUNTRY. Only meaningful for store cards, so setting it implies include_details — the light appid list carries no price.
steamidNo17-digit SteamID64. Omit to use the STEAM_ID configured on the server. Convert a vanity/custom URL name with resolve_vanity_url first.
languageNoStore language; overrides STEAM_LANGUAGE. Only meaningful for store cards, so setting it implies include_details — the light appid list carries no price.
platformNoNATIVE-build filter: keep only games shipping a native build for this OS (windows/mac/linux). 'linux' = a native Linux/SteamOS port. This is NOT Proton — for games that run via Proton compatibility use steam_os / steam_deck instead. Each result's `platforms` field lists its native builds, while steam_os/steam_deck report Proton compatibility, so native vs Proton stay distinct.
steam_osNoSteamOS compatibility — how well it runs on SteamOS in general (via Proton): 'verified' = SteamOS-Verified only; 'playable' = Playable or Verified. For a NATIVE Linux build instead, use platform:'linux'; for the Steam Machine console specifically, use steam_machine.
min_reviewNoKeep only items with at least this positive-review %. Implies include_details.
steam_deckNoSteam Deck compatibility (runs via Proton): 'verified' = Deck-Verified only; 'playable' = Playable or Verified. Not a native Linux build — see `platform` for that.
steam_frameNoSteam Frame (VR headset) compatibility: 'verified' = Frame-Verified only; 'playable' = Playable or Verified.
min_discountNoKeep only items discounted at least this %, ranked by discount. Implies include_details.
on_sale_onlyNoOnly wishlist items currently discounted, ranked by discount %. Implies include_details.
steam_machineNoSteam Machine (Valve's console) compatibility (via Proton): 'verified' = Steam-Machine-Verified only; 'playable' = Playable or Verified. Its own rating, distinct from the general steam_os one.
include_detailsNoReturn full store cards (name, price, discount, reviews, compatibility, tags) per item in one call, instead of just appids. Implied by any filter below.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Behavior5/5

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

Beyond annotations (readOnlyHint, openWorldHint), the description details behavior: returns found:false for private profiles, caps (100 light, 60 detailed), filtering before cap, ranking logic, and Steam's limitation on store data enrichment. No contradictions with annotations.

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 description is long but well-structured, starting with the core purpose and progressively adding detail. While every sentence adds value, the length is justified by the tool's complexity (13 optional parameters, many with interdependencies). Minor redundancy could be trimmed.

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 the tool's complexity, the description covers all necessary aspects: prerequisites, conditions, cap behavior, ranking, field explanations (returned, total, matched, enriched, note), filter interactions, and edge cases. The presence of an output schema doesn't reduce the need for this level of detail.

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 coverage is 100% with descriptions, so the parameter semantics baseline is high. The tool description adds meaningful context (e.g., implications of country/language, distinction between native and Proton, filter interactions) that enhances understanding beyond schema alone.

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 clearly states the verb 'List' and resource 'a player's Steam wishlist', specifying the identifier (SteamID64). It distinguishes from siblings by focusing exclusively on wishlist functionality and mentioning alternatives like get_items for follow-up calls.

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

Usage Guidelines5/5

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

The description provides explicit conditions (public profile required; returns found:false otherwise), when to use include_details vs separate calls, how to narrow results with filters, and prerequisites (use resolve_vanity_url first). It also explains ranking and cap behavior.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Grinv/steam-games-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server