Skip to main content
Glama
bielacki

IGDB MCP Server

by bielacki
OverviewSchemaRelated ServersScoreDiscussions
Python
Remote

IGDB MCP Server

Access the IGDB (Internet Game Database) API through Model Context Protocol (MCP)

Python MCP FastMCP uv License: MIT IGDB API

Overview

The IGDB MCP Server provides seamless access to the Internet Game Database (IGDB) through the Model Context Protocol. IGDB is a comprehensive database containing information about video games, including:

  • Game metadata (titles, descriptions, ratings)

  • Release dates and platforms

  • Developer and publisher information

  • Genres, themes, and game modes

  • User ratings and hype metrics

  • Cover art and media

Key Features

  • Full IGDB API Access: Search games, get detailed information, find trending titles

  • Smart Caching: OAuth tokens are cached to minimize authentication overhead

  • Flexible Queries: Use simple searches or advanced Apicalypse query language

  • Pre-built Prompts: Common queries ready to use

  • Type-Safe: Built with Pydantic for robust data validation

Related MCP server: Video Games MCP Server

Quick Start

Get IGDB Credentials

  1. Create a Twitch account (if you don't have one)

  2. Go to Twitch Developer Console → Register Your Application

  3. Get your Client ID and generate a Client Secret

📖 Full IGDB authentication guide

Option A: install via Smithery

To install igdb-mcp-server automatically via Smithery:

npx -y @smithery/cli install @bielacki/igdb-mcp-server

Option B: install with uvx

Install uv.

Add this to your MCP client's configuration:

{
  "mcpServers": {
    "igdb-mcp": {
      "command": "uvx",
      "args": ["--from", "git+https://github.com/bielacki/igdb-mcp-server.git", "igdb-mcp-server"],
      "env": {
        "IGDB_CLIENT_ID": "your_client_id",
        "IGDB_CLIENT_SECRET": "your_secret"
      }
    }
  }
}

Start Exploring

Start exploring with these example prompts:

🔍 Search & Discovery

  • "Search for Elden Ring and its expansions"

  • "Find all Persona games from the last 5 years"

  • "Show me games similar to Hades"

📊 Game Information

  • "Get details about Baldur's Gate 3"

  • "Tell me everything about Cyberpunk 2077 including DLC"

  • "What platforms is Hogwarts Legacy available on?"

🔥 Trending & Popular

  • "What are the most anticipated upcoming games?"

  • "Show me the highest rated indie games of 2024"

  • "Find games with the most hype right now"

🎯 Advanced Queries

  • "Find games similar to Skyrim with a rating of 85 or higher"

  • "List all games by Larian Studios"

  • "Show upcoming Silent Hill and Resident Evil games"

Core Components

Tools

Tool

Description

Parameters

Example Usage

search_games

Search for games by name

• query (required): Search term• fields: Fields to return (default: basic info)• limit: Results count (1-500, default: 10)

"Search for Elden Ring games"

get_game_details

Get comprehensive game information

• game_id (required): IGDB game ID• fields: Fields to return (default: extensive)

"Get details for game ID 1942"

get_most_anticipated_games

Find upcoming games by hype

• fields: Fields to return• limit: Results count (1-500, default: 25)• min_hypes: Min hype count (default: 25)

"Show most anticipated games"

custom_query

Execute Apicalypse queries

• endpoint (required): API endpoint• query (required): Apicalypse query string

"Find RPGs rated above 90"

Resources

Resource

Description

Returns

igdb://endpoints

List of all IGDB API endpoints

Available endpoints with descriptions

igdb://query-syntax

Apicalypse query language guide

Syntax reference and examples

Pre-built Prompts

Prompt

Description

Use Case

search_game

Formatted game search results

Quick game discovery with clean output

game_details

Comprehensive game information

Full details including ratings, platforms, developers

most_anticipated

Trending upcoming games

Discover hyped unreleased games with statistics

Troubleshooting

Authentication Errors

  • "IGDB_CLIENT_ID not set": Check your MCP client config has the env variables

  • "Invalid credentials": Verify your Client ID and Secret are correct

  • "Token expired": The server handles token refresh automatically

Rate Limiting

IGDB allows 4 requests per second. The server doesn't implement rate limiting, so:

  • Avoid rapid repeated queries

  • Use field expansion instead of multiple requests

  • Leverage multi-query for batch operations

Common Query Issues

  • No results: Check spelling, try broader search terms

  • Missing fields: Some fields may be null; handle gracefully

  • Query syntax error: Verify Apicalypse syntax, check semicolons

Environment Variables

Ensure your MCP client config includes:

"env": {
  "IGDB_CLIENT_ID": "abc123...",
  "IGDB_CLIENT_SECRET": "xyz789..."
}

License & Credits

MIT License - see LICENSE file for details

Credits:

For more information about IGDB API capabilities, visit the official IGDB API documentation.

Available Tools

4 tools
custom_queryCustom IGDB QueryBInspect

Run a custom Apicalypse query against any IGDB API endpoint

ParametersJSON Schema
NameRequiredDescriptionDefault
endpointYesThe API endpoint to query (e.g., 'games', 'companies', 'platforms', 'people', 'characters')
queryYesThe Apicalypse query string

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3.1/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. While it mentions 'Apicalypse query' (implying a specific query language/syntax), it doesn't address authentication requirements, rate limits, error handling, response format, or whether this is a read-only vs. mutation operation. The description provides minimal behavioral context beyond the basic action.

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, efficient sentence that communicates the core functionality without any wasted words. It's appropriately sized for a tool with two parameters and good schema documentation, and the information is front-loaded with the essential action and target.

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 has an output schema (which handles return values), 100% parameter schema coverage, and no complex nested objects, the description is minimally adequate. However, for a flexible query tool with no annotations and specialized sibling tools, it should provide more guidance about when to use it versus the alternatives and more context about the Apicalypse query language.

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?

With 100% schema description coverage, the input schema already fully documents both parameters (endpoint and query). The description doesn't add meaningful semantic context beyond what's in the schema descriptions, such as explaining Apicalypse syntax in more detail or providing endpoint usage patterns. The baseline of 3 is appropriate when the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Run a custom Apicalypse query') and target resource ('against any IGDB API endpoint'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'search_games' or explain when to use this more flexible tool versus the specialized ones.

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?

The description provides no guidance about when to use this tool versus the sibling tools (get_game_details, get_most_anticipated_games, search_games). There's no mention of prerequisites, alternatives, or specific scenarios where this custom query approach is preferable to the more specialized tools.

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

get_game_detailsGet Game DetailsBInspect

Retrieve detailed information about a specific game from IGDB

ParametersJSON Schema
NameRequiredDescriptionDefault
game_idYesThe IGDB ID of the game
fieldsNoComma-separated list of fields to returnid,slug,name,rating,rating_count,hypes,first_release_date,platforms.name,genres.name,status,cover.url,summary,involved_companies.company.name,involved_companies.developer,involved_companies.publisher

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

B3.2/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 the full burden of behavioral disclosure. It states the tool retrieves information, implying a read-only operation, but does not cover aspects like rate limits, authentication needs, error handling, or response format. This is a significant gap for a tool with no annotation coverage.

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, efficient sentence that directly states the tool's purpose without unnecessary words. It is appropriately sized and front-loaded, with every part earning its place.

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 tool's moderate complexity (2 parameters, 1 required), 100% schema coverage, and the presence of an output schema, the description is reasonably complete. It covers the core purpose, though it lacks behavioral details and usage guidelines, which are partially mitigated by the structured data.

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 both parameters thoroughly. The description adds no additional meaning beyond what the schema provides, such as examples or constraints for the 'fields' parameter. Baseline 3 is appropriate when the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb ('Retrieve') and resource ('detailed information about a specific game from IGDB'), making the purpose evident. However, it does not explicitly differentiate from sibling tools like 'search_games' or 'get_most_anticipated_games', which might also retrieve game information, so it lacks sibling distinction.

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?

The description provides no guidance on when to use this tool versus alternatives. It does not mention scenarios like needing details for a known game ID compared to searching by name or fetching anticipated games, leaving the agent without explicit usage context.

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

get_most_anticipated_gamesGet Most Anticipated GamesBInspect

Fetch upcoming games sorted by hype count, filtered for future or TBA releases

ParametersJSON Schema
NameRequiredDescriptionDefault
fieldsNoComma-separated list of fields to returnid,slug,name,hypes,first_release_date,platforms.name,genres.name,status
limitNoMaximum number of results to return
min_hypesNoMinimum number of hypes required

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3.3/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 mentions sorting and filtering behavior, but lacks critical details: it doesn't specify if this is a read-only operation, whether it requires authentication, rate limits, pagination, or what happens with invalid parameters. For a tool with no annotations, this leaves significant behavioral gaps unaddressed.

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, efficient sentence that front-loads the core purpose without unnecessary words. Every element ('Fetch upcoming games', 'sorted by hype count', 'filtered for future or TBA releases') contributes directly to understanding the tool's function. It's appropriately sized for its complexity.

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 100% schema coverage and an output schema exists, the description doesn't need to explain parameters or return values. However, with no annotations and a tool that involves filtering and sorting, it should provide more behavioral context (e.g., read-only nature, error handling). It's minimally adequate but has clear gaps in transparency for a tool with this functionality.

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 fully documents all three parameters. The description adds no parameter-specific information beyond what's in the schema (e.g., it doesn't explain 'hypes' or 'TBA' in more detail). Baseline score of 3 is appropriate as the schema does the heavy lifting, but the description doesn't compensate with additional semantic context.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Fetch'), resource ('upcoming games'), and key sorting/filtering criteria ('sorted by hype count, filtered for future or TBA releases'). It distinguishes from siblings like 'get_game_details' (specific game) and 'search_games' (general search), though it doesn't explicitly name alternatives. The purpose is specific but could be slightly more distinct from 'custom_query'.

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 retrieving highly anticipated games based on hype, but provides no explicit guidance on when to use this tool versus alternatives like 'search_games' or 'custom_query'. It mentions filtering criteria but doesn't state prerequisites, exclusions, or comparative scenarios. Usage is contextually implied rather than explicitly defined.

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

search_gamesSearch GamesBInspect

Search for games in the IGDB database

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesSearch term for finding games
fieldsNoComma-separated list of fields to returnname,rating,rating_count,first_release_date,platforms.name
limitNoMaximum number of results to return

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3.1/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 the full burden of behavioral disclosure. It states the tool searches for games but doesn't describe key behaviors such as how results are sorted, whether it's paginated, if there are rate limits, or what authentication might be required. This leaves significant gaps for an agent to understand operational constraints.

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, efficient sentence: 'Search for games in the IGDB database'. It's front-loaded with the core action and resource, with no unnecessary words or redundancy. Every part of the sentence contributes directly to understanding the tool's purpose.

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 moderate complexity (3 parameters, 1 required) and the presence of an output schema (which handles return values), the description is minimally adequate. However, it lacks context on behavioral traits (e.g., sorting, pagination) and usage guidelines relative to siblings, making it incomplete for optimal agent decision-making despite the structured support.

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?

The description adds no parameter-specific information beyond what's already in the input schema, which has 100% coverage with clear descriptions for 'query', 'fields', and 'limit'. Since schema coverage is high, the baseline score is 3, as the description doesn't compensate with additional semantics like example queries or field usage tips.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Search for games in the IGDB database'. It specifies the verb ('search') and resource ('games'), and identifies the database context. However, it doesn't explicitly differentiate from sibling tools like 'custom_query' or 'get_most_anticipated_games', which likely also involve game searches or queries.

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?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'custom_query' (which might offer more flexible queries) or 'get_game_details' (which might retrieve specific game information), nor does it specify contexts where this search is preferred over others. Usage is implied but not articulated.

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

Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.4/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: custom_query is for raw API queries, get_game_details retrieves specific game info, get_most_anticipated_games fetches upcoming games by hype, and search_games performs general searches. There is no overlap in functionality, making tool selection straightforward for an agent.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern (e.g., custom_query, get_game_details, get_most_anticipated_games, search_games). The naming is uniform and predictable, using snake_case throughout with clear action descriptors.

Tool Count3/5

With only 4 tools, the server feels slightly thin for interacting with a comprehensive database like IGDB. While the tools cover key operations, more specialized functions (e.g., filtering by genre, platform, or date) might be missing, making the count borderline for the domain's scope.

Completeness3/5

The tools provide basic search and retrieval capabilities but lack full CRUD/lifecycle coverage typical of a database API. There are notable gaps, such as no update or delete operations (though IGDB might be read-only), and limited filtering options beyond hype-based sorting, which could hinder complex agent workflows.

Maintenance

ActivityInactive
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • GameBrain Video Game Discovery

    ddsky
    A
    license
    Not graded
    quality
    D
    maintenance
    earch and discover hundreds of thousands of video games on any platform through the GameBrain API.
    4
    Apache 2.0

  • Video Games MCP Server

    BaranDev
    A
    license
    Not graded
    quality
    D
    maintenance
    Provides direct access to the RAWG gaming database, allowing users to search for games, retrieve detailed metadata, and explore genres within Claude. It streamlines game research by offering information on ratings, platforms, and release dates through natural language queries.
    3
    MIT

  • thegamesdb

    pipeworx-io
    A
    license
    Not graded
    quality
    C
    maintenance
    Wraps TheGamesDB API to enable game data queries via MCP. Part of Pipeworx gateway connecting AI agents to live data sources.
    17
    MIT

  • boardgames

    pipeworx-io
    A
    license
    Not graded
    quality
    D
    maintenance
    Enables users to search and retrieve board game data via the Board Game Atlas API, including game details, ratings, and availability.
    17
    MIT

Appeared in Searches

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/bielacki/igdb-mcp-server'

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