Skip to main content
Glama
brewek

GG Deals MCP Server

by brewek
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

mcp-server-ggdeals

CI

A Model Context Protocol (MCP) server for integrating with gg.deals. Designed for Large Language Models to fetch game prices, historical lows, and bundles.

Installation & Usage

Use npx to run the server instantly in your MCP Client (e.g., Claude Desktop). No cloning required.

claude_desktop_config.json:

{
  "mcpServers": {
    "ggdeals": {
      "command": "npx",
      "args": ["-y", "mcp-server-ggdeals"],
      "env": {
        "GG_DEALS_API_KEY": "your_api_key_here"
      }
    }
  }
}

You can generate your API key at https://gg.deals/settings/ -> Connections -> GG.deals API key.

Related MCP server: isthereanydeal-mcp

Available Tools

`

  • search_games: Find a base game ID by title. (Note: This tool queries Steam Store API to retrieve Steam App ID, which is used for all gg.deals api calls).

  • get_game_prices: Fetch current prices (Official & Keyshops).

  • get_historical_low: Fetch the all-time lowest price.

  • get_game_bundles: Fetch Premium/Deluxe DLC bundles linked to a base game.

Architecture

Minimalist and modular codebase built with TypeScript and Zod:

  • src/index.ts: MCP routing & initialization

  • src/api.ts: Shared Axios client & error handling

  • src/search.ts: Search logic

  • src/prices.ts: Pricing & historical data

  • src/bundles.ts: Bundles discovery

Development

npm install
npm run build
npm run dev

Available Tools

4 tools
get_game_bundlesA

Fetch specific bundles and packages (like Premium Editions) associated with a base game ID.

ParametersJSON Schema
NameRequiredDescriptionDefault
gameIdYesThe unique base Steam App ID

TDQS

A3.8/5.0
Behavior3/5

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

No annotations provided; description indicates a read-only fetch. However, it does not disclose potential errors, limits, or response behavior beyond 'fetch'.

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?

Single sentence, no wasted words, front-loaded with clear verb and resource.

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 simple read tool with one parameter and no output schema, the description adequately covers the main purpose. Could mention outcome format, but sufficient.

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% for the single parameter, and the description adds minimal value by rephrasing 'base game ID' as 'base Steam App ID'.

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 tool fetches bundles and packages for a game ID, using specific verb and resource. It distinguishes from sibling tools like get_game_prices and search_games.

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?

The description implies usage for fetching bundles but lacks explicit when-to-use or when-not-to-use guidance. No alternatives are mentioned.

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

get_game_pricesA

Get the current prices and deals for a specific game across various stores.

ParametersJSON Schema
NameRequiredDescriptionDefault
gameIdYesThe unique Steam App ID
regionNoThe region code for pricing (default: 'us')

TDQS

A3.5/5.0
Behavior2/5

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

No annotations are provided, so the description must disclose behavioral traits. It only states it's a read operation ('get') but omits details like rate limits, error handling (e.g., invalid gameId), or response format. This is insufficient for a tool with no structural safety cues.

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, concise sentence that front-loads the core purpose. Every word is essential; no filler or redundancy. Ideal for quick parsing.

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?

Given the tool's simplicity (2 params, no output schema), the description is adequate but lacks details on return format, which stores are queried, or what qualifies as a 'deal'. The sibling tools indicate more nuanced options, but for basic price retrieval, it meets minimum needs.

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%, with both parameters described ('gameId' as Steam App ID, 'region' as region code with default). The tool description adds no extra meaning beyond the schema, meeting the baseline for high coverage but not enhancing understanding.

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 tool retrieves current prices and deals for a specific game across stores. The verb 'Get' and resource 'current prices and deals' are specific, and it distinguishes from siblings like 'get_game_bundles' which implies bundle deals, and 'get_historical_low' which focuses on historical data.

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?

No explicit guidance is given on when to use this tool versus alternatives. While the purpose is clear, the description lacks when-not-to-use advice or comparisons with sibling tools. However, for a straightforward price lookup, basic usage is implied.

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

get_historical_lowB

Get the all-time lowest recorded price for a specific game.

ParametersJSON Schema
NameRequiredDescriptionDefault
gameIdYesThe unique Steam App ID

TDQS

B3.4/5.0
Behavior2/5

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

No annotations provided, so the description carries the full burden. It does not disclose what happens if the gameId is invalid, whether the data is cached, or any error handling. Despite being a simple read, it lacks behavioral details.

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 concise sentence with no filler. It communicates the core functionality efficiently.

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?

Given the low complexity (1 parameter, no output schema, no annotations), the description provides sufficient information for an agent to understand what the tool does. However, it could be more complete by noting return behavior or data freshness.

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% with a single parameter 'gameId' described as 'The unique Steam App ID'. The description adds no additional meaning beyond the schema, so baseline score of 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 clearly states the verb 'Get', the resource 'all-time lowest recorded price', and the scope 'for a specific game'. It is distinct from siblings: get_game_bundles (bundles), get_game_prices (current prices), search_games (search). The purpose is immediately understandable.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives. No mention of when to avoid it or prerequisites. The description only states what it does, not the context of use.

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

search_gamesA

Search for video games by title on Steam. Use this to find a game's Steam App ID.

ParametersJSON Schema
NameRequiredDescriptionDefault
titleYesThe title of the game to search for
limitNoMaximum number of results to return (default: 10)

TDQS

A3.6/5.0
Behavior2/5

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

No annotations are provided, so the description carries full burden. It only states it searches and finds App ID, but omits behavioral traits like rate limits, data freshness, default limit, or search algorithm details.

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?

Two sentences, front-loaded with action and purpose. Very concise, but could include more detail without becoming verbose. Efficient use of text.

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?

No output schema, so description should hint at output format. It mentions finding App ID but lacks details on result structure, error handling, or pagination. Adequate for a simple search tool with well-documented parameters.

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% with descriptions for both parameters. Description adds minimal extra meaning (e.g., 'by title' mapping to the title parameter). Baseline 3 is appropriate since no additional significant semantics beyond schema.

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?

Description clearly states 'Search for video games by title on Steam' with a specific verb and resource, and explicitly distinguishes the tool's purpose from siblings like get_game_bundles, get_game_prices, and get_historical_low.

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?

Description says 'Use this to find a game's Steam App ID', providing clear context for when to use. It does not explicitly state when not to use or mention alternatives, but sibling tools imply different use cases.

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.8
    • Changedget_game_bundles1 field changed
      • changedInput schema / properties / gameId / description
        Previous value: -"The unique base game ID"New value: +"The unique base Steam App ID"
    • Changedget_game_prices1 field changed
      • changedInput schema / properties / gameId / description
        Previous value: -"The unique game ID from gg.deals"New value: +"The unique Steam App ID"
    • Changedget_historical_low1 field changed
      • changedInput schema / properties / gameId / description
        Previous value: -"The unique game ID from gg.deals"New value: +"The unique Steam App ID"
  2. 4 tool updatesv1.0.2
    • First observedget_game_bundles
    • First observedget_game_prices
    • First observedget_historical_low
    • First observedsearch_games
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 4 tools

Disambiguation5/5

Each tool targets a distinct purpose: search_games finds games by title, get_game_prices retrieves current prices, get_historical_low gets all-time lows, and get_game_bundles fetches package variants. There is no meaningful overlap or ambiguity between them.

Naming Consistency5/5

All tool names follow the same snake_case verb_noun pattern: search_games, get_game_prices, get_historical_low, get_game_bundles. The convention is uniform and predictable, making the tool set easy to navigate.

Tool Count5/5

With only 4 tools, the server is tightly scoped to its core purpose of looking up game pricing information. Each tool earns its place and the count feels appropriate rather than thin or bloated.

Completeness4/5

The server covers the primary workflow of searching for a game, checking current prices, viewing historical lows, and fetching bundles. Minor gaps exist such as browsing recent deals or filtering prices by store, but the surface is largely complete for its stated purpose.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches