Skip to main content
Glama
xiongxingzhe

wishlistdoc-mcp

by xiongxingzhe
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

🎮 WishlistDoc MCP Server

MCP License: MIT Node Website

The official Model Context Protocol (MCP) server for WishlistDoc — giving AI agents (Claude, Cursor, Windsurf, Claude Code, Cline) direct access to Steam store algorithmic health audits, empirical P10/P50/P90 sales cone forecasts, and indie game market benchmarks.

🌟 Why WishlistDoc MCP?

Steam's recommendation algorithm is responsible for over 70% of an indie game's organic reach. WishlistDoc MCP enables your AI development assistant to evaluate any Steam store page instantly and forecast commercial outcomes based on empirical industry datasets from GameDiscoverCo and Steamworks.

  • 🏥 Instant Store Page Health Audit: Evaluates 6 algorithmic dimensions (Tag precision, Localization depth, Price resistance, Demo loop, Visual pacing, Short description hook) and returns an S/A/B/C letter grade and prioritized prescriptions.

  • 📈 P10 / P50 / P90 Sales Cone Forecasting: Predicts first-week unit sales and first-year gross revenue under pessimistic, median, and viral breakout scenarios with subgenre conversion rates.

  • 📊 Subgenre Benchmarks: Queries baseline conversion rates, wishlist decay half-life curves (e.g. 270 days), and minimum launch thresholds across RPG, Action, Simulation, Horror, and Casual genres.

  • 🔗 Direct Web Report Integration: Every diagnostic returns deep links to interactive web reports on wishlistdoc.com.

Related MCP server: steamforecast-mcp

🚀 Quick Start

1. Claude Desktop

Add wishlistdoc-mcp to your claude_desktop_config.json:

  • macOS: ~/Library/Application Support/Claude/claude_desktop_config.json

  • Windows: %APPDATA%\Claude\claude_desktop_config.json

{
  "mcpServers": {
    "wishlistdoc": {
      "command": "npx",
      "args": ["-y", "wishlistdoc-mcp"]
    }
  }
}

2. Cursor (.cursor/mcp.json)

In your project root or user settings, configure .cursor/mcp.json:

{
  "mcpServers": {
    "wishlistdoc": {
      "command": "npx",
      "args": ["-y", "wishlistdoc-mcp"]
    }
  }
}

3. Claude Code CLI

Add the server via CLI command:

claude mcp add wishlistdoc-mcp -- npx -y wishlistdoc-mcp

4. Smithery (1-Click Install)

Install automatically via Smithery:

npx -y @smithery/cli install wishlistdoc-mcp --client claude

🛠️ Available MCP Tools

audit_steam_store

Audits the algorithmic readiness of any Steam store page by AppID.

Inputs:

  • appid (number, required): The Steam application ID (e.g., 105600 for Terraria, 1245620 for Elden Ring).

Returns:

  • Overall Store Health Score (0 - 100) and Grade (S, A, B, C, D, F)

  • 6-dimension score breakdown with status (OPTIMAL, WARNING, CRITICAL)

  • Primary subgenre detection & algorithmic traffic multiplier

  • Ranked action prescriptions with expected score boost and execution steps

  • Direct link to web audit report on wishlistdoc.com/report

predict_sales_cone

Forecasts launch performance and Year-1 gross revenue using empirical conversion models.

Inputs:

  • appid (number, required): The Steam application ID.

  • wishlists (number, optional): Pre-launch wishlist count. If omitted, empirical estimates based on reviews or median indie cohorts are used.

  • customPriceUSD (number, optional): Target launch price in USD (e.g. 19.99).

Returns:

  • Confidence tiers:

    • P10 (Pessimistic Floor): 90% probability above this floor (0.40x median).

    • P50 (Median Benchmark): Expected baseline for peer titles (1.0x).

    • P90 (Breakout Ceiling): Viral breakout tier (2.50x).

  • First-week unit sales & Year-1 estimated gross revenue.

  • Algorithmic multipliers (Localization, Demo, Pricing friction, Visual assets).

get_genre_benchmarks

Retrieves industry launch benchmarks and wishlist decay parameters.

Inputs:

  • genre (string, optional): Query specific genre ("rpg", "action", "simulation", "horror", "casual", or "all").

Returns:

  • Median first-week conversion percentage.

  • Year-1 lifetime revenue multiplier.

  • Wishlist decay half-life duration (in days).

  • Recommended minimum pre-launch wishlist target.

  • Key commercial drivers for the genre.

  • Link to wishlistdoc.com/benchmarks.

💬 Example AI Prompts

Once configured in Claude or Cursor, you can ask questions naturally:

  • "Audit my game on Steam (AppID: 2145320). What are the top 3 issues keeping it from getting algorithm recommendations?"

  • "We are launching our deckbuilder RPG with 18,000 wishlists at $19.99 USD. Predict our P10, P50, and P90 first-week sales and Year 1 revenue."

  • "What is the standard wishlist decay curve and launch conversion rate for an indie simulation game on Steam?"

🔬 Empirical Methodology

All models implemented in WishlistDoc MCP are grounded in:

  1. Simon Carless / GameDiscoverCo empirical Steam game discovery research.

  2. Steamworks Documentation recommendations for store metadata and regional localization.

  3. WishlistDoc 270-Day Half-Life Decay Equation: Accounts for the decaying purchase intent of older wishlists over time: $$\text{Effective Wishlists} = \sum W_i \cdot e^{-\lambda (t - t_i)}$$

🔗 Related Resources

📄 License

MIT © WishlistDoc

Available Tools

3 tools
audit_steam_storeA

Audit a Steam game store page health score (0-100), letter grade (S/A/B/C/D/F), 6 algorithmic dimensions (tags, localization, pricing resistance, demo loop, visual assets, short description), and prioritized actionable prescriptions. Powered by WishlistDoc (https://wishlistdoc.com).

ParametersJSON Schema
NameRequiredDescriptionDefault
appidYesThe Steam App ID (e.g. 105600 for Terraria, 1245620 for Elden Ring).

TDQS

A3.8/5.0
Behavior2/5

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

There are no annotations, so the description carries the full burden of behavioral disclosure. It does not state whether the operation is read-only, whether an external WishlistDoc service requires authentication or API keys, or how errors are handled for invalid appids. It only describes the output structure, leaving significant behavioral gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single front-loaded sentence that efficiently packs the verb, resource, output items, and a brief attribution. There is no fluff, and the most important information comes first.

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 does a good job of listing the return values (score, grade, dimensions, prescriptions). However, it does not address prerequisites or error behavior, such as what happens if the appid is invalid or whether external service limits apply.

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%: the appid parameter is fully described with examples. The description adds no additional parameter-level detail, so the 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?

The description uses the specific verb 'Audit' and clearly identifies the resource as 'Steam game store page health'. It enumerates the output components (score, grade, 6 dimensions, prescriptions), making the tool's purpose unmistakable. It is naturally differentiated from sibling tools like predict_sales_cone and get_genre_benchmarks by the action and output.

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?

The description gives clear context for when to use the tool (auditing a Steam store page's health) and explicitly lists what it returns. It does not explicitly mention alternatives or exclusions, but the context is clear enough for an agent to select it appropriately.

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

get_genre_benchmarksA

Retrieve Steam industry launch conversion benchmarks, Year-1 revenue multipliers, and 270-day wishlist decay curves for specific game genres (RPG, Action, Simulation, Horror, Casual, or all).

ParametersJSON Schema
NameRequiredDescriptionDefault
genreNoGenre name to query (e.g. "rpg", "action", "simulation", "horror", "casual", or "all").

TDQS

A4/5.0
Behavior3/5

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

With no annotations provided, the description carries the burden of behavioral disclosure. 'Retrieve' signals a read-only operation and the text lists the data categories returned, but it does not describe the output format, default behavior if genre is omitted, or possible error conditions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The entire description is one dense, front-loaded sentence with no filler. Every phrase contributes either the resource being retrieved or the accepted genre scope.

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?

For a one-parameter, read-only retrieval tool, the description clearly names the data being returned and the accepted genre values. Without an output schema, a bit more detail about return structure or the default when genre is omitted would make it fully complete, but it is sufficient for selection and invocation.

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%, so the schema already documents the genre parameter and its examples. The description repeats those examples but adds no new semantic information beyond what the schema provides.

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 uses a specific verb 'Retrieve' and names precise resources: Steam launch conversion benchmarks, Year-1 revenue multipliers, and 270-day wishlist decay curves. It also scopes by genre ('RPG, Action, Simulation, Horror, Casual, or all'), which makes it readily distinguishable from sibling tools like audit_steam_store and predict_sales_cone.

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?

The intended use is clear: fetch genre-specific Steam benchmark data. It does not explicitly state when not to use it or name alternative tools, but the context is unambiguous enough for an agent to select it appropriately.

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

predict_sales_coneA

Forecast Steam first-week unit sales and first-year gross revenue across P10 (pessimistic floor), P50 (median benchmark), and P90 (breakout ceiling) confidence tiers. Powered by WishlistDoc empirical game discovery models.

ParametersJSON Schema
NameRequiredDescriptionDefault
appidYesThe Steam App ID.
wishlistsNoOptional target or current pre-launch wishlist count. If omitted, an empirical estimate based on community size or median indie benchmark will be used.
customPriceUSDNoOptional simulation price in USD (e.g. 19.99). Overrides the store price or default placeholder.

TDQS

A3.9/5.0
Behavior3/5

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

No annotations are provided, so the description carries the burden. It discloses that the tool uses 'WishlistDoc empirical game discovery models' and that omitted wishlists are estimated, which is useful. However, it does not disclose whether this is a read-only operation, whether it makes external calls, or what the output format looks like. For a forecasting tool, the lack of output schema and return-format details is a moderate gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no filler. The core purpose and confidence tiers are front-loaded, and the model provenance is a single clause at the end. Every word earns its place.

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

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a forecasting tool with no output schema and no annotations, the description should ideally explain what the output looks like (e.g., a table of P10/P50/P90 values) and any assumptions about the input appid. The description covers the model source and optional parameters, but the missing return-format disclosure leaves an agent uncertain about how to interpret the result. Still, the core call is clear.

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%, so the schema already documents all three parameters. The description adds context about the optional wishlist behavior ('If omitted, an empirical estimate...') and the price override, which is helpful. However, it does not add much beyond the schema, so a baseline 3 is appropriate.

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 states a specific verb ('Forecast') and resource ('Steam first-week unit sales and first-year gross revenue') and specifies the three confidence tiers (P10/P50/P90). It clearly distinguishes this from sibling tools like audit_steam_store and get_genre_benchmarks, which are about auditing store data and genre benchmarks rather than forecasting sales.

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?

The description implies when to use this tool: when a sales forecast for a Steam game is needed, and it mentions the optional wishlist input and price override, which gives context for simulation scenarios. It does not explicitly state when not to use it or name alternatives, but the sibling names and the forecast-specific language make the use case clear enough.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 3 tool updatesv1.0.0
    • First observedaudit_steam_store
    • First observedget_genre_benchmarks
    • First observedpredict_sales_cone
Deploy Server
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

TDQS

A3.9/5.0

Scored across 3 tools

Disambiguation5/5

Each tool targets a distinct domain: store page audit, sales forecasting, and genre benchmarks. There is no overlap in purpose or output.

Naming Consistency4/5

All tool names use a consistent verb_noun pattern (audit_steam_store, predict_sales_cone, get_genre_benchmarks). Minor deviation: 'sales_cone' is a domain-specific term while the others are generic, but the pattern is consistent.

Tool Count4/5

Three tools is on the lower end but appropriate for a focused niche server covering audit, prediction, and benchmarks. It feels slightly thin but each tool is substantial and distinct.

Completeness3/5

The server covers core wishlist/sales analysis workflows, but lacks obvious related operations like fetching wishlist counts, comparing games, or updating/refreshing audits. Agents can work around gaps but the surface is minimal.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • steamforecast-mcp

    GC108
    A
    license
    A
    quality
    C
    maintenance
    Model Context Protocol server for Steam Launch Forecaster, exposing calibrated revenue cones (P10–P90) and other tools to AI agents for Steam game revenue forecasting and analysis.
    5
    MIT
  • Glitch MCP by Glitch-Gaming-Platform

    Glitch MCPofficial

    Glitch-Gaming-Platform
    A
    license
    A
    quality
    B
    maintenance
    Connects AI developer tools to the Glitch Agent service for game marketing tasks such as Steam analysis, influencer outreach, PR planning, and approval workflows.
    20
    20 npm
    1
    MIT
  • PeepTrend MCP Server by PeepTrend

    PeepTrend MCP Serverofficial

    PeepTrend
    A
    license
    A
    quality
    D
    maintenance
    Provides AI agents with tools for gaming creator research, including checking YouTube channel conflicts, title competition, gaming niches, and Steam update opportunities.
    13
    59 npm
    MIT