This server connects AI assistants to The Game Crafter (TGC) API, enabling you to design, manage, and price tabletop games through natural conversation.
Authentication & Session Management
Authenticate with TGC using stored credentials and log out to destroy the session.
Component Catalog Exploration
Browse the full TGC printable component catalog (cards, boards, boxes, etc.) with optional category filtering.
Retrieve pixel dimensions, bleed, and safe zone specs for artwork preparation.
Game Project Management
List designer profiles and associated games (paginated).
Create new game projects, update their name, description, or public visibility, and permanently delete them.
Get full game details including components, files, and pricing.
Component & File Management
Add printable components (card decks, boards, boxes, etc.) or stock parts to a game with specified quantities.
Upload image files to TGC folders from local disk or a public URL.
Pricing Estimation
Get per-component cost breakdowns and total pricing estimates at various order quantities.
Guided Workflows
Use step-by-step guided prompts for setting up a new game project or estimating game costs.
An MCP server that connects AI assistants to The Game Crafter API, letting you design, manage, and price tabletop games through natural conversation.
Browse the component catalog, create game projects, add card decks and boards, upload artwork, and get instant pricing estimates — all through your AI assistant.
Indie board game designers, tabletop creators, and TGC users who want to manage their projects through an AI assistant instead of navigating the TGC web interface manually.
Related MCP server: undesirables-mcp-server
Node.js 18 or later
A TGC account — sign up here
A TGC API key — generate one here
Connect to the hosted server at:
https://chillbot3000--tgc-mcp-server.apify.actor/mcpNo local setup required. Provide your TGC credentials when you call the authenticate tool. Usage is billed per operation via Apify's pay-per-event model (~$0.09 per typical session).
Also available on Glama Connectors.
Add the server to your Claude Desktop configuration (~/Library/Application Support/Claude/claude_desktop_config.json on macOS):
{
"mcpServers": {
"thegamecrafter": {
"command": "npx",
"args": ["-y", "@alex-gon/tgc-mcp-server"],
"env": {
"TGC_API_KEY_ID": "your-api-key-id",
"TGC_USERNAME": "your-tgc-username",
"TGC_PASSWORD": "your-tgc-password"
}
}
}
}Restart Claude Desktop. The server will be downloaded automatically and appear in your MCP connections.
git clone https://github.com/alex-gon/thegamecrafter-mcp-server.git
cd thegamecrafter-mcp-server
npm install && npm run buildThen use "command": "node" and "args": ["/absolute/path/to/dist/index.js"] in the config above.
Variable | Required | Description |
| Yes | Your TGC API key ID |
| Yes | Your TGC account username |
| Yes | Your TGC account password |
| No | API base URL (defaults to |
| No | Restrict file uploads to this directory (defaults to working directory) |
See .env.example for a template.
Tool | Description | Auth |
| Create a TGC session (accepts credentials as params or uses env vars) | No |
| Destroy the current TGC session | Yes |
| Browse printable component types (cards, boards, boxes) | No |
| Get pixel dimensions and finished inches for component types | No |
| Get detailed info for a component type or game part | No |
| List designer profiles for the authenticated user | Yes |
| List all games for a designer (paginated) | Yes |
| Get full game info with components, files, and pricing | Yes |
| Create a new game project under a designer | Yes |
| Update a game's name, description, or visibility | Yes |
| Permanently delete a game project | Yes |
| Add a printable component or stock part to a game | Yes |
| Upload an image to a TGC folder (from disk or URL) | Yes |
| Get per-component cost breakdown for a game | Yes |
URI | Description |
| Full catalog of printable component types (cached 30 min) |
| Complete summary of a game project |
| Pixel dimensions for all component types (cached 30 min) |
Prompt | Description |
| Guided workflow for creating a complete game project with components |
| Step-by-step cost estimation for an existing game |
Try saying these to your AI assistant:
"Show me all my games on The Game Crafter with their component lists"
"Create a new card game called Stellar Drift with a standard poker deck and tuck box"
"What pixel dimensions do I need for a poker card face image?"
"Upload this image and assign it as the front face of my card deck"
"Estimate the cost of my game based on its current components"
"Help me set up a new game project from scratch — walk me through it"
"What component types are available for board games?"
"Delete my test game project"
Rate limits — The server enforces 3 requests/second to TGC (below their 4/sec limit) with per-session budgets of 500 reads and 200 writes.
Authentication — Credentials can be passed as authenticate tool parameters (required for remote usage) or via environment variables (for local stdio). OAuth 2.1 support is planned for a future release.
File uploads — Maximum 50 MB per file. Images must be between 50x50 and 10,000x10,000 pixels. Supported formats: PNG, JPG, GIF, BMP, TIFF, SVG, WebP, PDF.
Transport — Stdio for local usage. Remote HTTP available via the hosted Apify endpoint.
Read-only catalog — The component catalog and pricing come from TGC and cannot be modified.
Bug reports and pull requests are welcome. Please open an issue first to discuss what you'd like to change.
To run the development server:
cp .env.example .env # fill in your credentials
npm run dev # starts with tsx + hot reload
npm test # run the test suiteAdd a printable component (card deck, board, box, etc.) or stock part to a game. Use a catalog identity (e.g., 'BridgeDeck') for printable components, or a stock part UUID. Requires authentication.
| Name | Required | Description | Default |
|---|---|---|---|
| game_id | Yes | The game ID to add the component to. | |
| part_id | Yes | The component identity from the catalog (e.g., 'BridgeDeck', 'SmallTuckBox') or a stock part UUID. | |
| quantity | Yes | Number of this component to include (e.g., 52 for a deck of cards). | |
| name | No | Optional display name for this component within the game (max 255 chars). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond the readOnlyHint annotation (which only indicates it's not read-only) by specifying authentication requirements, which is useful context. However, it lacks details on behavioral traits like whether the operation is idempotent, potential side effects, error conditions, or rate limits, leaving gaps in transparency.
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 front-loaded with the core purpose in the first sentence, followed by usage details and authentication requirement. Every sentence adds value without redundancy, making it efficient and well-structured for quick understanding.
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 complexity (a mutation with authentication) and lack of output schema, the description is moderately complete. It covers the purpose, usage, and auth needs, but omits details on return values, error handling, or interactions with other tools like get_component_details, which could aid the agent in proper 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?
With 100% schema description coverage, the schema already documents all parameters well. The description adds minimal semantics by mentioning catalog identities and stock part UUIDs for part_id, but does not provide additional meaning beyond what the schema offers, such as examples for game_id or name usage.
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 action ('Add'), the resource ('a printable component or stock part'), and the target ('to a game'). It distinguishes from siblings by specifying component types (cards, boards, boxes) and using catalog identities or UUIDs, unlike generic tools like update_game or get_game_details.
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 provides clear context on when to use this tool: for adding components to games, with examples of component types and identifiers. It mentions authentication as a prerequisite. However, it does not explicitly state when not to use it or name alternatives among siblings, such as using update_game for other modifications.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a TGC session using stored credentials. Must be called before any tool that requires authentication.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable context beyond annotations: it explains that this tool establishes a session for authentication, which is crucial for understanding its behavioral impact. Annotations only indicate it's not read-only, but the description clarifies its purpose in enabling other tools. No contradiction with annotations exists.
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 front-loaded and concise, with two sentences that efficiently convey purpose and usage guidelines. Every sentence earns its place without unnecessary details, making it easy for an agent to parse.
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 complexity (authentication setup), no output schema, and minimal annotations, the description is mostly complete. It explains what the tool does and when to use it, but could benefit from mentioning potential errors or session details. However, it adequately covers the essentials for an agent to invoke it correctly.
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?
With 0 parameters and 100% schema coverage, the description doesn't need to explain parameters. It appropriately focuses on the tool's purpose and usage, adding no redundant information. A baseline of 4 is justified as it compensates for the lack of parameters by emphasizing context.
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 specific action ('Create a TGC session') and resource ('using stored credentials'), distinguishing it from sibling tools like 'logout' or other authentication-related operations. It precisely communicates the tool's function without being tautological.
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 states when to use this tool ('Must be called before any tool that requires authentication'), providing clear context and prerequisites. This helps the agent understand its role as an initialization step in the workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new game project under a designer. Requires authentication.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Name for the new game project (max 255 chars). | |
| designer_id | Yes | The designer ID to create the game under. Get this from the get_my_designers tool. | |
| description | No | Optional description for the game (max 5000 chars). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond annotations by mentioning authentication requirements, which annotations do not cover. However, it lacks details on behavioral traits such as what happens on success/failure, rate limits, or idempotency. With annotations indicating it's not read-only (readOnlyHint: false), the description aligns but could provide more context.
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 highly concise and front-loaded, consisting of a single sentence that directly states the tool's purpose and a key requirement. There is no wasted language, making it efficient and easy to understand.
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 complexity as a creation operation with no output schema and annotations only covering read-only status, the description is minimally complete. It mentions authentication but lacks details on return values, error handling, or how it integrates with sibling tools, leaving gaps in context.
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 description does not add parameter-specific semantics beyond what the input schema provides, as schema description coverage is 100% with clear descriptions for each parameter. The baseline score of 3 is appropriate since the schema adequately documents parameters without extra value from the description.
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 action ('Create a new game project') and target resource ('under a designer'), making the purpose evident. However, it does not explicitly differentiate this tool from sibling tools like 'update_game' or 'delete_game', which would require mentioning it's for initial creation only.
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 provides some usage context by stating 'Requires authentication' and implying the need for a designer ID, but it does not explicitly guide when to use this tool versus alternatives like 'update_game' or how it relates to other tools such as 'get_my_designers' for obtaining the designer ID. Usage is implied rather than clearly defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Permanently delete a game project. This action cannot be undone.
| Name | Required | Description | Default |
|---|---|---|---|
| game_id | Yes | The game ID to delete. This action is permanent and cannot be undone. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, indicating a destructive write operation. The description adds valuable context by emphasizing permanence ('permanently delete', 'cannot be undone'), which reinforces the destructive nature beyond what annotations provide. It doesn't mention authentication needs or rate limits, but with annotations covering safety profile, this is acceptable.
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 extremely concise with two sentences that are front-loaded and waste-free. The first sentence states the core action, and the second provides critical behavioral context. Every word earns its place, making it easy to parse quickly.
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 complexity (destructive operation with 1 parameter) and rich annotations (destructiveHint=true), the description is mostly complete. It covers the irreversible nature, which is crucial. However, with no output schema, it doesn't describe return values (e.g., success confirmation or error messages), leaving a minor gap in completeness.
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 100%, with the parameter 'game_id' fully documented in the schema. The description doesn't add any parameter-specific information beyond what's in the schema, such as format examples or constraints. Baseline 3 is appropriate when the schema handles parameter documentation effectively.
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 specific action ('permanently delete') and target resource ('a game project'), distinguishing it from sibling tools like 'create_game', 'update_game', and 'get_game_details'. It provides a precise verb+resource combination that leaves no ambiguity about the tool's function.
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 usage context through the warning 'This action cannot be undone', suggesting it should be used cautiously. However, it doesn't explicitly state when to use this tool versus alternatives like 'update_game' for modifications or provide prerequisites (e.g., authentication status). The guidance is present but not comprehensive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a component type by catalog identity (e.g., 'BridgeDeck') or a game part by UUID.
| Name | Required | Description | Default |
|---|---|---|---|
| part_id | Yes | The component identity from the catalog (e.g., 'BridgeDeck') or a game part UUID. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations indicate readOnlyHint=true, which the description aligns with by using 'Get' (implying a read operation). The description adds context by specifying the types of identifiers accepted (catalog identity or UUID), but does not disclose additional behavioral traits like rate limits, error handling, or output format, which would be helpful given the lack of output schema.
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 that directly states the tool's purpose without unnecessary words. It is front-loaded with the core action and resource, making it easy to parse and understand quickly.
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 (one parameter, read-only per annotations) and lack of output schema, the description is adequate but incomplete. It does not explain what 'detailed information' includes or potential response formats, which could hinder the agent's ability to use the tool effectively without trial and error.
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 100%, with the parameter 'part_id' fully documented in the schema. The description adds minimal semantics by clarifying that 'part_id' can be a catalog identity (e.g., 'BridgeDeck') or a UUID, but this is redundant with the schema's description. Thus, it meets the baseline without significant added value.
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 ('Get detailed information') and resource ('about a component type by catalog identity or a game part by UUID'), making the purpose evident. However, it does not explicitly differentiate from sibling tools like 'get_component_sizes' or 'get_game_catalog', which might also retrieve component-related information, so it lacks sibling distinction for a perfect score.
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 provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, such as needing authentication, or compare it to siblings like 'get_component_sizes' or 'get_game_catalog', leaving the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get pixel dimensions (width, height, bleed, safe zone) and finished inches for TGC component types. Use this to determine correct image sizes before uploading artwork. No authentication required.
| Name | Required | Description | Default |
|---|---|---|---|
| part_id | No | Optional component identity from the catalog (e.g., 'BridgeDeck'). Omit to list all component types. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, indicating a safe read operation. The description adds valuable context beyond this by specifying that 'No authentication required,' which is not covered by annotations and is crucial for usage. However, it doesn't disclose other behavioral traits like rate limits, error handling, or response format, leaving some gaps.
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 front-loaded with the core purpose in the first sentence, followed by usage context and authentication note. Every sentence earns its place by providing essential information without redundancy, making it efficient and easy to parse for an AI agent.
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 low complexity (one optional parameter, read-only operation) and good annotations, the description is mostly complete. It covers purpose, usage, and authentication needs. However, without an output schema, it doesn't explain return values (e.g., format of dimensions), which is a minor gap in context for a sizing 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?
The input schema has 100% description coverage, with the parameter 'part_id' well-documented in the schema itself. The description does not add any additional meaning or examples beyond what the schema provides (e.g., it doesn't elaborate on 'TGC component types' or 'finished inches'), so it meets the baseline for high schema coverage without compensating with extra insights.
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 specific action ('Get pixel dimensions... and finished inches') and resource ('TGC component types'), distinguishing it from siblings like get_component_details (which likely provides other metadata) or get_game_catalog (broader scope). It explicitly mentions the purpose ('determine correct image sizes before uploading artwork'), making the tool's role unambiguous.
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 provides explicit guidance on when to use this tool ('before uploading artwork') and distinguishes it from alternatives by specifying its focus on dimensions for TGC components. It also clarifies when not to use it by implying it's for sizing information only, not for other component details handled by siblings like get_component_details.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Browse TGC printable component types (cards, boards, boxes, etc.). No authentication required.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Optional category to filter products (e.g., "cards", "boards", "boxes"). Omit to list all. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable context beyond annotations: it explicitly states 'No authentication required' (which isn't covered by readOnlyHint alone) and clarifies the scope ('printable component types'). The annotations already declare readOnlyHint=true, so the description doesn't contradict them and provides useful behavioral information.
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 perfectly concise with two sentences: the first states the purpose and scope, the second adds critical behavioral context. Every word earns its place, and it's front-loaded with the core functionality.
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 catalog browsing tool with one optional parameter and readOnlyHint annotation, the description is nearly complete. It covers purpose, scope, and authentication context. The only minor gap is lack of output format information (no output schema exists), but this is acceptable for this complexity level.
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?
With 100% schema description coverage, the schema already fully documents the single optional parameter. The description doesn't add any parameter-specific information beyond what's in the schema, so it meets the baseline of 3 for adequate coverage without extra value.
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 specific action ('Browse') and resource ('TGC printable component types'), with explicit examples of what's included ('cards, boards, boxes, etc.'). It distinguishes from siblings like get_component_details (specific details) or get_my_games (user-specific).
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 states when to use this tool ('No authentication required') and implies when not to use it (for user-specific data, use get_my_games or get_my_designers). It provides clear context for browsing general catalog vs. authenticated operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get full game info including name, description, component list with quantities, file references, and pricing. Use this to review a game before making changes. Requires authentication.
| Name | Required | Description | Default |
|---|---|---|---|
| game_id | Yes | The game ID to get details for. Get this from the get_my_games tool. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable context beyond the readOnlyHint annotation by stating authentication requirements ('Requires authentication') and clarifying the tool's purpose for review before changes. While it doesn't mention rate limits or pagination, it provides useful behavioral guidance that complements the annotation.
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 perfectly concise with three sentences that each serve distinct purposes: stating what the tool returns, when to use it, and prerequisites. There's no wasted verbiage, and the most critical information (what data is returned) 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?
For a read-only tool with good annotations and a simple single-parameter schema, the description provides excellent context about authentication, usage timing, and data scope. The only minor gap is lack of output format details (though no output schema exists), but overall it's highly complete for this complexity level.
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?
With 100% schema description coverage, the schema already fully documents the single 'game_id' parameter. The description doesn't add any parameter-specific details beyond what's in the schema, so it meets the baseline for high schema coverage.
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 specific action ('Get full game info') and enumerates the exact data returned (name, description, component list with quantities, file references, and pricing). It distinguishes this tool from siblings like 'get_game_catalog' (likely listing games) and 'get_component_details' (focusing on components).
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 explicitly states when to use this tool ('Use this to review a game before making changes') and implies alternatives by mentioning prerequisites ('Get this from the get_my_games tool'). It clearly positions this as a read-before-write tool, distinguishing it from mutation tools like 'update_game' or 'create_game'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List designer profiles for the authenticated user. Returns designer ID, name, and user ID. Use the designer_id with get_my_games or create_game. Requires authentication.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable context beyond the readOnlyHint annotation by specifying authentication requirements and how the output (designer_id) integrates with other tools. While it doesn't detail rate limits or pagination, it provides meaningful behavioral guidance that enhances the annotation.
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 front-loaded with the core purpose, followed by usage guidance and prerequisites in three efficient sentences. Every sentence adds value without redundancy.
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 read-only tool with no parameters and no output schema, the description is nearly complete—it covers purpose, usage, and authentication. A minor gap is the lack of output format details (e.g., pagination or error handling), but overall it's well-suited to the tool's simplicity.
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?
With 0 parameters and 100% schema coverage, the baseline is 4. The description appropriately notes there are no inputs by not discussing parameters, which aligns with the empty 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 the specific action ('List designer profiles'), target resource ('for the authenticated user'), and output details ('designer ID, name, and user ID'). It distinguishes itself from siblings like 'get_my_games' by focusing on designer profiles rather than 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?
The description explicitly states when to use this tool ('Use the designer_id with get_my_games or create_game') and provides prerequisites ('Requires authentication'). It clearly differentiates from alternatives by specifying its output is used as input for other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all games for a designer with name, ID, and status. Returns paginated results. Requires a designer_id from get_my_designers. Requires authentication.
| Name | Required | Description | Default |
|---|---|---|---|
| designer_id | Yes | The designer ID to list games for. Get this from the get_my_designers tool. | |
| page_number | No | Page number for pagination (default: 1). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, indicating a safe read operation. The description adds valuable behavioral context beyond this: it discloses that results are paginated and that authentication is required. This enhances the agent's understanding of usage constraints, though it could mention rate limits or error handling for a higher score.
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 highly concise and front-loaded: it states the core purpose in the first clause, followed by key behavioral details (pagination, prerequisites, authentication). Every sentence earns its place with no wasted words, making it efficient for an agent to parse.
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 moderate complexity (list operation with pagination and authentication), no output schema, and rich annotations (readOnlyHint), the description is mostly complete. It covers purpose, behavior, and prerequisites, but could improve by detailing the return format (e.g., structure of name, ID, status) or error cases, which are not addressed.
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 100%, meaning the input schema fully documents both parameters. The description adds minimal semantic value: it reiterates that designer_id comes from 'get_my_designers' (already in the schema) and mentions pagination (implied by the page_number parameter). This meets the baseline for high schema coverage but does not significantly enhance understanding.
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 tool's purpose: 'List all games for a designer with name, ID, and status.' It specifies the verb ('List'), resource ('games'), and scope ('for a designer'), but does not explicitly distinguish it from sibling tools like 'get_game_catalog' or 'get_game_details', which prevents a perfect score.
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 provides clear context for when to use this tool: 'Requires a designer_id from get_my_designers.' This indicates a prerequisite and guides the agent to use 'get_my_designers' first. However, it does not specify when not to use it or mention alternatives like 'get_game_catalog', so it falls short of a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get per-component cost breakdown and total price for a game at various order quantities. The game must have components added first via add_component_to_game. Requires authentication.
| Name | Required | Description | Default |
|---|---|---|---|
| game_id | Yes | The game ID to get pricing for. The game must have components added. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, and the description adds valuable context beyond this by specifying authentication requirements and prerequisites (components must be added first via another tool). It does not contradict annotations, but it could provide more behavioral details like rate limits or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by prerequisites and authentication in two concise sentences. Every sentence adds necessary information without redundancy, making it efficient and well-structured.
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 complexity (pricing estimates with multiple quantities), the description is mostly complete with purpose, prerequisites, and authentication. However, without an output schema, it lacks details on return values (e.g., format of cost breakdown), which could be helpful for an agent. The annotations cover safety, but more behavioral context could enhance completeness.
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 description coverage is 100%, with the parameter 'game_id' fully documented in the schema. The description adds minimal semantic context by reiterating that the game must have components added, but this is already implied in the usage guidelines. Baseline 3 is appropriate as the schema handles most of the parameter documentation.
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 tool's purpose with specific verbs ('Get per-component cost breakdown and total price') and resources ('for a game at various order quantities'), distinguishing it from siblings like get_game_details or get_component_details by focusing on pricing estimates rather than general game or component information.
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 provides clear context for when to use this tool by stating prerequisites ('The game must have components added first via add_component_to_game') and authentication requirements. However, it does not explicitly mention when not to use it or name alternatives, such as get_game_details for non-pricing information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Destroy the current TGC session.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond the destructiveHint annotation by specifying what gets destroyed ('current TGC session'), which helps the agent understand the scope of the destructive operation. While annotations already indicate destructive behavior, the description clarifies the specific target, enhancing transparency without contradicting annotations.
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, front-loaded sentence with zero wasted words. Every word ('Destroy', 'current', 'TGC session') contributes essential meaning, making it maximally efficient and well-structured for immediate comprehension.
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 (0 parameters, destructive annotation, no output schema), the description is complete enough for an agent to understand and invoke it correctly. It covers the core action and target, though it could optionally mention side effects like requiring re-authentication afterward, but this isn't strictly necessary for basic functionality.
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?
With 0 parameters and 100% schema description coverage, the baseline is 4. The description appropriately doesn't discuss parameters since none exist, and it doesn't need to compensate for any schema gaps, making it fully adequate for this parameterless tool.
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 specific action ('Destroy') and target resource ('current TGC session'), distinguishing it from sibling tools like 'authenticate' which creates sessions. It uses precise terminology that leaves no ambiguity about its function.
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 usage context by specifying 'current TGC session' destruction, suggesting it should be used when ending an authenticated session. However, it doesn't explicitly state when to use it versus alternatives or provide exclusion criteria, though the context is reasonably clear from the tool's nature.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update a game's name, description, or visibility. Requires authentication.
| Name | Required | Description | Default |
|---|---|---|---|
| game_id | Yes | The game ID to update. | |
| name | No | New name for the game (max 255 chars). | |
| description | No | New description for the game (max 5000 chars). | |
| is_public | No | Whether the game should be publicly visible in the TGC shop. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds 'Requires authentication' which is useful context beyond the annotations (which only indicate readOnlyHint: false). However, it doesn't disclose other behavioral traits like whether updates are partial (only specified fields) or full, what happens on success/failure, rate limits, or if changes are reversible. With annotations covering the mutation aspect, this adds some value but lacks depth.
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 that front-loads the core purpose and includes an essential constraint (authentication). There's no wasted verbiage or redundancy, making it easy to parse quickly.
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 complexity (mutation with 4 parameters, no output schema), the description is minimally adequate. It covers the what and an auth requirement but lacks details on behavior, error handling, or output expectations. With annotations providing some safety context (non-read-only), it's passable but could be more informative for a mutation 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?
The description lists the updatable fields (name, description, visibility), which aligns with the input schema parameters. Since schema description coverage is 100%, the schema already documents each parameter thoroughly (e.g., max lengths, boolean meaning). The description adds no additional semantic context beyond what's in the schema, so it meets the baseline for high coverage.
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 ('update') and resource ('game'), specifying the fields that can be modified (name, description, visibility). It distinguishes from siblings like 'create_game' or 'delete_game' by focusing on modification rather than creation or deletion. However, it doesn't explicitly differentiate from tools like 'add_component_to_game' which also modifies games but in a different way.
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 provides no guidance on when to use this tool versus alternatives. It mentions authentication as a requirement but doesn't specify prerequisites like having an existing game ID or compare it to other update-related tools (e.g., 'add_component_to_game'). There's no mention of when not to use it or what happens if parameters are omitted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Upload an image file to a TGC folder for use in a game component. This is a heavyweight operation — avoid calling repeatedly in quick succession. Requires authentication.
| Name | Required | Description | Default |
|---|---|---|---|
| folder_id | Yes | The folder ID to upload the file into. Components have associated folder IDs. | |
| file_path | No | Absolute path to the image file on disk. Provide either file_path or url, not both. | |
| url | No | Public URL of the image to download and upload to TGC. Provide either url or file_path, not both. | |
| filename | No | Optional filename to use in TGC (max 255 chars). Required when uploading from URL. Defaults to the original filename when uploading from disk. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only indicate it's not read-only (readOnlyHint: false). The description adds valuable behavioral context: it's a 'heavyweight operation' with a warning about rate limits ('avoid calling repeatedly in quick succession'), and it 'requires authentication'. This goes beyond annotations by disclosing performance and auth traits, though it doesn't detail error handling or exact rate limits.
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 front-loaded with the core purpose, followed by critical behavioral warnings and requirements. Every sentence earns its place: the first states the action, the second adds performance context, and the third specifies auth needs. It's appropriately sized with zero waste.
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 complexity (file upload with auth and performance considerations), the description covers key aspects: purpose, behavioral warnings, and auth. However, there's no output schema, and the description doesn't hint at return values or error cases. With good annotations and schema coverage, it's mostly complete but could benefit from output or error context.
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 100%, so the schema already documents all parameters thoroughly. The description doesn't add any parameter-specific semantics beyond what's in the schema (e.g., it doesn't explain folder_id sourcing or file format constraints). Baseline 3 is appropriate as the schema carries the full burden.
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 ('upload') and resource ('image file to a TGC folder'), and specifies the purpose ('for use in a game component'). It doesn't explicitly differentiate from sibling tools like 'add_component_to_game' or 'update_game', but the focus on file upload is distinct enough for a 4.
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 provides some context ('heavyweight operation — avoid calling repeatedly in quick succession') and mentions authentication requirements, but it doesn't explicitly state when to use this tool versus alternatives (e.g., if there are other upload methods or sibling tools for similar purposes). This gives implied usage guidance but lacks explicit alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a distinct, well-defined purpose with no overlap. For example, get_component_sizes is purely for dimensions, while get_component_details provides component info, and add_component_to_game is for adding components to games. The descriptions clearly differentiate actions like create_game, update_game, and delete_game.
All tool names follow a consistent verb_noun pattern (e.g., add_component_to_game, create_game, get_game_details). The naming is uniform across all 14 tools, using snake_case throughout with clear action verbs like 'get', 'create', 'update', and 'delete'.
With 14 tools, this server is well-scoped for managing game projects on The Game Crafter platform. It covers authentication, game lifecycle, component management, file uploads, and pricing, which aligns perfectly with the domain's needs without being excessive or insufficient.
The toolset provides complete coverage for the game design and publishing workflow. It includes authentication (authenticate/logout), game CRUD (create_game, get_my_games, update_game, delete_game), component handling (add_component_to_game, get_component_details, get_component_sizes), file management (upload_file), and pricing (get_pricing_estimate), with no apparent gaps for core operations.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Game-dev sprite tools: PNG/GIF to spritesheet, split, trim, animate. OAuth-authenticated MCP server.
15 tools for chess variant analysis, hex map generation, and board game utilities
Hosted MCP: 1404 structured web-data tools for search, maps, commerce, social, gaming & finance.
Boardgames MCP — wraps Board Game Atlas API (public demo client_id, free)
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/alex-gon/thegamecrafter-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
