The steam-mcp server registers 14 tools across multiple categories but exhibits significant definition quality gaps. Only 2 tools are directly visible in the provided source code (deals, diagnostics). The remaining 12 tools are inferred from registration functions in index.ts but their actual schemas and descriptions are not provided for evaluation. For visible tools: 'deals' has a basic enum-based schema with 4 parameters but lacks depth in parameter descriptions (e.g., 'Steam ID' is vague, is this a profile URL, numeric ID, or username?). The description 'Sale checks, wishlist, deals, library value' is a comma-separated list rather than a narrative explanation of when/why to use it. 'diagnostics' similarly has minimal parameter descriptions ('Log type to parse', 'Number of lines to return') without context on valid ranges or error handling. Neither tool documents output schema. Visible tools show basic constraint handling (enums) but lack idempotency guidance, error recovery hints, and output documentation.
Visible tool descriptions are non-narrative lists ('Sale checks, wishlist, deals, library value') rather than actionable explanations of WHAT the tool does, WHEN to use it, and what it returns. Under 50 characters and lacks LLM-optimized structure.
Parameter descriptions for visible tools are minimal (e.g., 'Steam ID', 'Number of lines to return') without format hints, range constraints, or error recovery guidance. 'Steam ID' is ambiguous, is it a profile URL, numeric app/account ID, or display name?
dealsdiagnostics
Recommendations
Add comprehensive schema definitions to all 14 tools. For each, document: input parameter types, descriptions, constraints (min/max, enums, patterns), and the complete output schema with field types and descriptions.
Rewrite tool descriptions as narrative explanations: '[WHAT] This tool checks current Steam game sales and wishlists. [WHEN] Use it when a user asks about deals, sales, or library value estimates. [RETURNS] Object with {appid, name, current_price, original_price, discount_percent, on_wishlist, playtime_hours}.' Aim for 100-200 characters.
Expand parameter descriptions with format hints and constraints. E.g., 'appid: Steam application ID (numeric, e.g. 570 for Dota 2). Optional, if not provided, check requires a game name.' Similarly, 'lines: number of log lines to return (1-500, default 50). Omit to get last 50 lines.'
No visible output schemas documented for any tool. Agents cannot infer what fields to expect or plan downstream chaining. Returns are presumed but not specified.
No error handling guidance visible. Tools that call Steam APIs (deals, player, workshop via inferred functions) can fail, no recovery hints, retryability classification, or actionable error messages documented.
Tool names like 'deals', 'diagnostics', 'games', 'library', 'status' are nouns or generic terms, not verb-based action names. LLMs expect 'get_', 'list_', 'search_', 'check_'. E.g., 'check_deals' or 'search_games_by_name' are clearer than 'deals' or 'games'.
The 'deals' tool combines multiple concerns: 'check_sale', 'wishlist_deals', 'wishlist', 'library_value'. This is a composition violation, should be split into check_game_sale, get_wishlist_deals, get_wishlist, get_library_value so agents can invoke each independently.
Optional parameter 'appid' in 'deals' tool, no documentation on when it is required vs optional for each action. E.g., does 'check_sale' require appid but 'library_value' does not? This ambiguity forces LLM guessing.
deals
Document error scenarios for each tool. E.g., for 'deals': 'If STEAM_API_KEY is not set, returns {error: "API key required, set STEAM_API_KEY environment variable"}. If appid is invalid, returns {error: "Invalid app ID. Try search_games() with the game name first."}. If Steam API times out, returns {error: "Steam API timeout. Retry in 5 seconds."}.'
Add tool annotations (readOnlyHint, idempotentHint) via MCP SDK to signal safety. All 14 tools appear to be read-only (no state modification), mark them with readOnlyHint: true.
Document which tools accept natural identifiers (game name, player username) vs which require numeric IDs (appid), and explain resolution behavior. E.g., 'search_games accepts game names (e.g., "The Witcher 3"); returns appid for use with other tools.'
Add pagination guidance to tools that return lists (library, workshop, etc.). E.g., 'limit (default 20, max 100): number of items to return. Use offset or next_cursor for pagination.'
For API-dependent tools (deals, player, workshop), document timeout behavior and retry guidance. E.g., 'If Steam API returns 503, this is retryable, wait 10s and retry.'