Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@gamelibs-mcp show me my top 5 most played Steam games"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server that exposes your Steam, Epic Games Store, and IGDB game data as tools an MCP client (Claude Code / Desktop) can call.
Steam — owned games, playtime, and installed-on-this-machine status.
Epic — owned library + install status, via the reverse-engineered endpoints used by the open-source Legendary CLI / Heroic.
IGDB — a games metadata database, for enriching/looking up game info.
Example prompt you could use once this MCP is set up:
Give me the top 5 of the games I own in my Steam and Epic library and I have not played yet but should play next.
I'm currently looking for a multiplayer game I can play online with my friends; since we played a lot of FPS games recently we want to try something different and more chill this time, maybe more collaborative like some Tower Defense or a Survival game.
Use the games I've already played as a baseline to get a sense of my overall taste but also don't hesitate to interview me to refine your understanding of what I am currently in the mood for.
Steam — steam_list_games, steam_get_game_details, steam_resolve_user
Epic — epic_auth_status, epic_get_login_url, epic_login, epic_list_games, epic_get_game_details
IGDB — igdb_search_games, igdb_get_game_details, igdb_lookup_by_steam_appid
Cache — refresh_cache (flush cached data so the next call re-fetches; the igdb_*
tools also take force_refresh for refreshing specific games)
Lean responses. This keeps large libraries from blowing up the model's context.
Tools split into thin list tools (ids/titles only) and fat detail tools that take a sublist of ids.
Everything is paginated (limit/offset) and filterable server-side (search, installed_only, sort).
No image/cover URLs are ever returned
DLCs are excluded unless you pass include_dlcs=True.
Per-machine install detection.
"Installed" data lives only in local files: Steam's .acf manifests, the official Epic Games Launcher's *.item manifests, and/or Legendary/Heroic's installed.json.
Run this server on the machine you actually game on to get real install status.
Owned/playtime data works from anywhere.
Windows, macOS, and Linux layouts are supported (the official Epic launcher is Windows/macOS only).
Related MCP server: mcp-steam
Requires Python 3.11+. Download or Clone the repo, then run it locally.
uv is recommended:
uv sync # or: pip install -e ".[dev]"Credentials are read from environment variables:
Variable | Needed for | How to get it |
| Steam | |
| Steam | your SteamID64, or your |
| IGDB |
Those will typically be provided as environment variables in your MCP client's configuration (e.g. claude_desktop_config.json, see "Set up in Claude" below), but can also be provided via a .env file (see "Contributing - Developer Tips").
Epic does not need static secrets. If you already use Legendary/Heroic on this machine, Epic auth is bootstrapped from their local user.json. Otherwise, your MCP client is expected to call epic_get_login_url, have you open the returned URL in your browser to sign in to Epic like normal, then call epic_login(<authorizationCode>).
For Steam, GetOwnedGames only returns data if your profile's Game details privacy is set to Public (and "Always keep my total playtime private" is off).
For Claude Code, you can add the MCP by running the following command from the cloned working copy directory:
claude mcp add gamelibs \
--env STEAM_API_KEY=... --env STEAM_ID=... \
--env TWITCH_CLIENT_ID=... --env TWITCH_CLIENT_SECRET=... \
-- uv run --directory "$PWD" python -m gamelibs_mcpIf you are using Claude Desktop, go to "Settings" > "Developer" > "Edit Config" then add this to the claude_desktop_config.json file (see also .mcp.json.example):
"mcpServers": {
"gamelibs": {
"type": "stdio",
"command": "uv",
"args": ["run", "--directory", "<mcp path on disk>", "python", "-m", "gamelibs_mcp"],
"env": {
"STEAM_ID": "<see above>",
"STEAM_API_KEY": "<see above>",
"TWITCH_CLIENT_ID": "<see above>",
"TWITCH_CLIENT_SECRET": "<see above>"
}
}
}Be sure to replace the values of the env vars with your actual credentials (see above), as well as the <mcp path on disk> with the actual absolute path to where you cloned the repo (If you're on Windows, don't forget to escape backslashes (e.g. C:\\Users\\...) in that path).
.env fileThe MCP can read your credentials from env vars declared in a local .env file too. Simply cp .env.example .env and fill it in with your actual credentials.
While this is not the ideal option for integrating the MCP in Claude (where you'd usually prefer to use claude mcp add gamlibs --env ... --env ... or the "env" attribute in the JSON config, like described above), having the ability to store your credentials in a local .env file can be very useful when working on the MCP's code itself for debugging or contributing, to avoid having to export them globally in your shell or having to pass them to every call while you test and iterate on the MCP.
On startup the server loads .env files searched from the directory it is launched in, upward. This works for uv run mcp dev … (launched from the project root) and for a claude mcp add … --directory <project> registration (launched in the project dir). It does not magically work if the server is launched from an unrelated directory.
The MCP Inspector is a nice tool for developers who are working on any MCP. It's not specific to this gamelibs MCP in particular, but I find this useful so figured I'd share.
To use it, simply run this command from the root of your repo's working copy:
uv run mcp dev src/gamelibs_mcp/server.pyThis MCP Inspector requiresNode.js / npx to run
uv run pytest # offline unit tests (file-format parsing, install detection)The Epic integration talks to undocumented, reverse-engineered endpoints (as Legendary/Heroic do). It may break if Epic changes them, and is for personal use with your own account.
Report Epic auth state (does a valid/refreshable token exist, and from where).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden, and it does so well: 'Report' signals a read-only status operation, and the parenthetical precisely scopes what is checked and what kind of answer is produced. It does not discuss side effects like token refresh, but the description's explicit 'report' framing makes the expected behavior reasonably transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly written sentence. The parenthetical adds essential precision without bloat, and the core action is front-loaded. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-argument status tool with no output schema, the description covers the essential facts: what is reported and the key detail the caller cares about (valid/refreshable token and its source). It does not spell out the exact return shape, but for this low-complexity tool the description is adequate for an agent to invoke it and interpret its result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, and the schema correctly reflects that with an empty properties object. Since there is nothing for the description to clarify about parameters, the baseline of 4 applies; no additional parameter documentation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Report') and a clear resource ('Epic auth state'), then sharpens the meaning with the parenthetical: 'does a valid/refreshable token exist, and from where.' This clearly differentiates it from siblings like epic_login and epic_get_login_url, which are about establishing auth rather than reporting on it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when this tool is appropriate: any time an agent needs to know the current Epic auth state. It does not explicitly name alternatives or state when not to use it, but the purpose is self-evident enough to guide selection among the sibling auth-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full text details for specific Epic games (title, description, developer, install info).
Args: app_names: Epic app_name identifiers (from epic_list_games), max 50 per call. include_dlcs: Include entries that are DLC (excluded by default).
| Name | Required | Description | Default |
|---|---|---|---|
| app_names | Yes | ||
| include_dlcs | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden of disclosing behavior. It mentions the default DLC exclusion and the 50-item limit, but it does not state whether the call is read-only, whether authentication is required, whether results are cached, or what errors or edge cases might occur. For a no-annotation tool, this is a meaningful transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded: a one-sentence purpose followed by compact parameter definitions. Every sentence earns its place, and there is no redundant repetition of the tool name or schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter detail lookup, the description covers the core invocation needs: what to pass, where the identifiers come from, and a key option's default behavior. However, with no output schema and no annotations, it omits return structure, authentication dependencies, and any relation to auth or cache-refresh siblings, leaving some practical context unresolved.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no descriptions, so the Args section fully compensates. It explains that app_names are Epic app_name identifiers from epic_list_games and cap at 50 per call, and it clarifies include_dlcs as a way to include DLC entries while excluded by default. This adds substantial meaning beyond the raw schema types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource (specific Epic games) and the content returned (title, description, developer, install info), which makes the tool's purpose obvious. However, it relies on the tool name for the verb 'get' and does not explicitly contrast itself with sibling detail tools like igdb_get_game_details or steam_get_game_details, so it stops short of full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The Args section says app_names come 'from epic_list_games', which implies a two-step workflow: list games first, then fetch details. It also explains the include_dlcs default. But it gives no explicit guidance on when to choose this tool over the other get-details siblings, no exclusions, and no mention of prerequisites such as authentication.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the Epic login URL. Sign in there, then copy the authorizationCode for epic_login.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the behavioral burden. It does disclose the interactive nature: the user must sign in and copy an authorizationCode. However, it omits details like URL expiry, side effects, or whether existing authentication affects the call.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. The primary action is front-loaded, and the second sentence adds necessary flow context. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description provides the essential return value and the next step in the auth flow. It omits minor context such as exact output format or URL expiration, but nothing prevents a correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is effectively complete, so the baseline is 4. The description does not need to describe parameter behavior, and it introduces no parameter ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Get the Epic login URL.' It also clearly positions itself as the precursor to epic_login, distinguishing this tool from its sibling that actually consumes the authorizationCode.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear sequential guidance: get the URL, sign in there, then copy the authorizationCode for epic_login. It does not explicitly enumerate when-not-to-use cases or alternatives, so it stops short of a top score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List owned Epic games (thin: app_name, catalog_item_id, namespace, title, installed).
The first call warms a persistent catalog-metadata cache (titles + game/DLC categories), so it may be slow on a large library; subsequent calls are fast. Only a page is returned.
Args: installed_only: Only games installed here (via local Legendary/Heroic state). search: Case-insensitive substring match on the title. include_dlcs: Include DLC/add-on entries (excluded by default). limit: Page size (1-500). Use pagination for large libraries. offset: Pagination offset.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No | ||
| search | No | ||
| include_dlcs | No | ||
| installed_only | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full behavioral disclosure burden. It does well by explaining the cache-warming latency on first call, persistent cache behavior, that only one page is returned, and the local Legendary/Heroic state source for installed_only. It does not mention authentication prerequisites or error behavior, but it is otherwise strong.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a one-sentence functional summary, a brief performance note, and a clean Args block. Every sentence adds useful information with no repetition or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, no annotations, and no output schema, the description covers the essential invocation details: output fields, pagination, caching, and filtering semantics. It does not describe the exact page response envelope or authentication state assumptions, but it is close to complete for a read/list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so all parameter meaning must come from the description. It fully compensates: installed_only is tied to local game installation state, search is a case-insensitive substring on title, include_dlcs explains DLC exclusion by default, and limit/offset are given explicit pagination semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'List owned Epic games', then enumerates the exact output fields. This clearly distinguishes it from siblings like epic_get_game_details (single-game details) and steam_list_games (Steam library).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The tool's purpose—listing the user's owned Epic games—is clearly stated, and pagination behavior is explained. It does not explicitly name alternatives or conditions like 'use igdb_search_games for metadata', but the resource-specific scope gives adequate context. The lack of explicit when-not guidance keeps it from a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Exchange an Epic authorizationCode (from epic_get_login_url) for a stored session.
| Name | Required | Description | Default |
|---|---|---|---|
| authorization_code | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the behavioral disclosure burden. It mentions 'stored session,' implying a persistent state change, but does not explain side effects, authorization-code single-use behavior, session overwrite semantics, or error conditions. This is thin for an auth mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with no filler. The key scoping information, including the source sibling, is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description leaves important gaps: what the tool returns, possible failure modes (e.g., invalid or expired code), and what 'stored session' means for subsequent steps. For an essential auth step, this is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning by specifying the parameter is an Epic authorizationCode obtained from epic_get_login_url, beyond the schema's bare string type. However, it omits format, expiration, or how the code should be passed, so compensation is partial.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Exchange an Epic authorizationCode ... for a stored session.' It clearly identifies the input source (epic_get_login_url) and the outcome, which lets an agent distinguish this from sibling tools like epic_auth_status or epic_get_login_url.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'from epic_get_login_url' explicitly places this tool after that step in the login flow, giving clear contextual usage. It does not spell out when-not-to-use or alternative conditions, but the intended sequence is evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full text metadata for specific IGDB game ids (summary, ratings, genres, companies...).
Results are cached on disk per id. Set force_refresh=True to bypass the cache and pull fresh data for these ids (e.g. when the prompt asks for the latest ratings).
Args: ids: IGDB game ids (from igdb_search_games / igdb_lookup_by_steam_appid), max 50 per call. include_dlcs: Include ids that are DLC/expansions (excluded by default). force_refresh: Re-fetch from IGDB and overwrite the cached records for these ids.
| Name | Required | Description | Default |
|---|---|---|---|
| ids | Yes | ||
| include_dlcs | No | ||
| force_refresh | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It discloses on-disk caching per id, the default exclusion of DLCs, and that force_refresh overwrites cached records. It does not mention potential rate limits or error behavior, but the key side effects and refresh semantics are clearly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the core purpose, followed by caching behavior and an Args block. Every sentence adds useful information, and the formatting makes it easy for an agent to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, the description covers the essential invocation details: purpose, parameter semantics, defaults, caching, and refresh behavior. It stops short of specifying the exact output shape or error handling, but the agent has enough to call it correctly for the common cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description's Args section fully compensates by explaining every parameter: ids come from specific sources with a max of 50, include_dlcs defaults to excluding DLCs, and force_refresh refetches and overwrites cache. This adds crucial meaning beyond the bare property names and types in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb and resource: it retrieves full text metadata for specific IGDB game ids, listing example fields like summary, ratings, genres, and companies. The reference to IGDB ids and sister tools in the Args section helps differentiate it from search and platform-specific detail tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool by stating it is for specific IGDB ids obtained from igdb_search_games or igdb_lookup_by_steam_appid, and even gives an explicit use case for force_refresh when the prompt asks for latest ratings. It does not explicitly name alternatives to avoid, but the source-tool references imply the workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Map Steam appids to IGDB games (id + name) — bridges a Steam library to IGDB metadata.
Args: appids: Steam appids (max 50 per call). force_refresh: Re-query IGDB and overwrite the cached matches for these appids.
| Name | Required | Description | Default |
|---|---|---|---|
| appids | Yes | ||
| force_refresh | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the caching behavior (force_refresh overwrites cached results) and the per-call limit of 50 appids. It does not mention authentication, rate limits, or error handling, but these are secondary for a simple lookup and the core behavior is addressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, with the core purpose in the first sentence and parameter details in a clear, minimal list. There is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and lack of an output schema, the description provides sufficient context: input parameters, output format (id+name), caching behavior, and call limit. It does not detail edge cases like an appid with no IGDB match, but for a simple lookup this is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description is the only documentation for parameters. It explains 'appids' as Steam appids with a max of 50, and 'force_refresh' as a flag to re-query IGDB and overwrite cache. This adds meaning that the schema's bare types lack, fully covering both parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Map' and the specific resource (Steam appids to IGDB games) and output (id + name). It distinguishes itself from sibling tools like igdb_search_games (search by name) and igdb_get_game_details (get by IGDB id) by focusing on the Steam-to-IGDB bridge.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool ('bridges a Steam library to IGDB metadata') and notes the maximum of 50 appids per call. However, it does not explicitly contrast with alternatives (e.g., when to use igdb_search_games instead) or state what happens when an appid has no match.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search IGDB by name (thin: id, name, release_year). Use igdb_get_game_details for more.
Args: query: Free-text game name to search for. include_dlcs: Include DLC/expansion results (excluded by default). limit: Page size (1-500, IGDB default 10). offset: Pagination offset.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | ||
| offset | No | ||
| include_dlcs | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses the thin output shape and the default exclusion of DLCs, which is useful. However, it does not mention whether authentication is required, possible rate limits, or how results are ordered/handled when no match is found. It stops short of a fully transparent behavioral profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: the main purpose and limitation are in the first sentence, the alternative is next, and the parameter list is tight. Every sentence earns its place with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only search tool with no output schema, the description provides the key return fields, parameter semantics, and a pointer to the details tool. It is largely complete for invocation, though it omits auth requirements and any mention of how errors or zero-result searches behave.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the parameter documentation must compensate. The description covers all four arguments: query as free-text, include_dlcs as DLC/expansion filtering, limit with an explicit 1-500 range, and offset as pagination. This is solid, though offset is described only minimally as 'Pagination offset'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Search IGDB by name'. It clearly states the thin result scope ('id, name, release_year') and explicitly points to igdb_get_game_details for more depth, which differentiates it from the most relevant sibling tool without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly names igdb_get_game_details as the alternative when more detail is needed, giving an agent a clear routing rule. It could also mention when to prefer other lookup methods like igdb_lookup_by_steam_appid, but for the search-vs-details decision the guidance is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Flush cached library/metadata data so the next call re-fetches from the network.
Use when data may be stale (e.g. "get the latest ratings/library" or after you've installed/bought games). Auth tokens are NOT cleared — this refreshes data, not login. For refreshing just a few specific games, prefer force_refresh on the igdb_* tools.
Args: target: Which caches to clear — "all" (default), "steam", "epic", or "igdb".
| Name | Required | Description | Default |
|---|---|---|---|
| target | No | all |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and meets it: it warns that cached data is flushed, clarifies the next call hits the network, and explicitly states auth tokens are NOT cleared. The data-vs-login distinction is exactly the behavioral context an agent needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short blocks each accomplish a distinct job: what it does, when to use/avoid, and parameter values. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter cache-clearing tool, the definition covers action, trigger conditions, exceptions, and all argument choices. The output format is not critical since invoking the tool successfully does not depend on it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the schema only says target is a string defaulting to 'all'. The description compensates by listing all valid target values ('all', 'steam', 'epic', 'igdb') and restating the default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('flush') and names the exact resource ('cached library/metadata data'), stating the consequential behavior that the next call re-fetches. This is clearly distinct from the sibling read/list/auth tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says when to use the tool (when data may be stale, after installs/purchases) and when not to (for a few specific games, prefer force_refresh on the igdb_* tools). It also rules out auth-token clearing, reducing misinvocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full details for specific Steam games: playtime breakdown + local install info.
Args: appids: Steam appids to fetch (max 50 per call). include_dlcs: Reserved; Steam DLC ownership is not separately derivable here.
| Name | Required | Description | Default |
|---|---|---|---|
| appids | Yes | ||
| include_dlcs | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the disclosure burden. It adds useful operational behavior: appids are capped at 50 per call and include_dlcs is effectively a no-op. However, it does not mention authentication requirements, side-effect guarantees, or the response shape, so some transparency gaps remain.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, with the purpose in the first line and parameter clarifications in compact bullet-like lines. Every sentence adds value, especially the reserved include_dlcs caveat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity tool with two parameters and no output schema, the description covers the essential call-critical details: what the tool returns, which parameters matter, and the batch limit. The remaining gaps are minor, such as auth preconditions and exact response structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does so well: appids are defined as Steam appids with a 50-per-call limit, and include_dlcs is explained as reserved because Steam DLC ownership is not derivable here. Both parameters gain meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool provides full details for specific Steam games, naming the two content areas: playtime breakdown and local install info. It clearly distinguishes itself from sibling tools like steam_list_games (library listing) and epic_get_game_details / igdb_get_game_details (non-Steam or cross-platform lookups).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is clear context: use this when you need details for specific Steam appids. The description also gives a when-not signal by marking include_dlcs as reserved and noting that Steam DLC ownership is not separately derivable here. It does not explicitly name an alternative tool, but the intended use is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List owned Steam games (thin: appid, name, playtime, last-played, installed).
Args: installed_only: Only games installed on THIS machine (requires local Steam). search: Case-insensitive substring match on the game name. sort: One of "playtime" (desc), "name" (asc), "last_played" (desc). limit: Page size (1-500). offset: Pagination offset.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | playtime | |
| limit | No | ||
| offset | No | ||
| search | No | ||
| installed_only | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral burden. It usefully discloses the thin return shape, case-insensitive search behavior, sort semantics, and a local-Steam prerequisite. However, it omits other important traits such as authentication needs, data freshness/caching behavior, or pagination response behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The one-line purpose is front-loaded and instantly clear, followed by a compact Args block with no filler. Every sentence adds meaningful information about output or parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description appropriately names the returned fields and covers all parameters. It is nearly complete for correct invocation, though it could additionally mention whether Steam authentication is required and whether results are cached.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description fully compensates by explaining every parameter: installed_only, search case-insensitivity, exact sort options with ordering, limit range, and offset meaning. This goes well beyond the bare schema properties and is essential for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action and resource: 'List owned Steam games'. It also defines the exact fields returned with 'thin: appid, name, playtime, last-played, installed', which distinguishes it from detail-oriented siblings like steam_get_game_details and platform-specific siblings like epic_list_games.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides parameter-level context such as 'installed_only requires local Steam', but never explains when to choose this tool over alternatives like steam_get_game_details or epic_list_games. There is no explicit when/when-not guidance for selecting this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve a Steam vanity slug or profile URL to a SteamID64.
| Name | Required | Description | Default |
|---|---|---|---|
| vanity_or_url | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations and no output schema, the description carries the full behavioral burden. It states the core transformation and the accepted input shapes, but does not disclose behavior on invalid vanity names, error conditions, rate limits, or the exact return representation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence contains the entire contract with no filler. Every word adds semantic content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter resolver, the description is nearly sufficient: it defines input variants and the output type. The main missing piece is the exact return shape (string vs object) since there is no output schema, but the tool is simple enough that an agent can invoke it correctly from this definition.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no property description (0% coverage), so the description must clarify the parameter. It does: 'vanity_or_url' is a vanity slug or profile URL, which gives the agent the essential value format. It could be improved with examples or handling of trailing slashes, but it is substantially more meaningful than the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Resolve'), a precise input ('Steam vanity slug or profile URL'), and an unambiguous output ('SteamID64'). It is distinct from sibling tools that list or fetch game details rather than convert identifiers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use guidance or exclusions are provided; the tool does not mention alternatives or conditions under which it should be preferred. The intended use is inferable from the name and purpose, but the description itself carries no usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0epic_auth_statusepic_get_game_detailsepic_get_login_urlepic_list_gamesepic_loginigdb_get_game_detailsigdb_lookup_by_steam_appidigdb_search_gamesrefresh_cachesteam_get_game_detailssteam_list_gamessteam_resolve_userTools are cleanly separated by platform prefix (epic_, igdb_, steam_) and by action (search, list, get details, login, resolve). Each tool has a distinct target resource and operation, so there is no realistic ambiguity. The only cross-cutting tool, refresh_cache, is clearly distinct from per-id force_refresh parameters.
Names mostly follow a consistent <platform>_<verb>_<object> pattern, e.g. epic_list_games, igdb_search_games, steam_get_game_details. Minor deviations like epic_auth_status and epic_login are still readable and predictable, so the deviations are not confusing.
Twelve tools is well-scoped for a server that handles three platform integrations plus cache management. Each tool covers a necessary operation and none feel redundant or ornamental. The count sits comfortably in the ideal range.
The server covers the core library and metadata workflow well: list, get details, search, IGDB lookup, and cache refresh for all three platforms. Minor gaps exist, such as no Epic logout/revoke and no unified cross-platform library view, but these are workarounds rather than blockers.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
An MCP server that gives your AI access to the source code and docs of all public github repos
Hosted MCP server connecting claude.ai, ChatGPT and other AI apps to your own computer
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/AliSoftware/gamelibs-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
