BGG MCP provides access to the BoardGameGeek API through the Model Context Protocol, enabling retr…
Scored across 10 tools
Each tool targets a distinct capability: collection, details, hot, price, recommender, rules, search, thread-details, trade-finder, and user. Boundaries are explicitly clarified in the descriptions (e.g. bgg-search returns basic info while bgg-details deep-dives; bgg-rules finds forum threads while bgg-thread-details fetches full content).
All tools follow a consistent bgg- prefix with kebab-case naming, which is highly predictable. The convention is noun/descriptor-based rather than verb_noun, so the intended action is slightly less obvious from the name alone, but there is no mixing of styles.
Ten tools is squarely in the well-scoped range and each maps to a genuine BGG capability. No redundant or filler tools are present.
The surface covers discovery, detail, pricing, recommendations, rules lookup, trades, and user data fairly comprehensively for the BGG domain. Minor gaps exist around write operations (e.g. logging plays or managing collections) and listing threads by game, but core read workflows are covered.
Query a user's board game collection on BoardGameGeek (BGG). Returns all matching games by default with basic info (name, ID, rating, plays, status). Use the filter parameters to narrow results.
| Name | Required | Description | Default |
|---|---|---|---|
| owned | No | ||
| rated | No | ||
| played | No | ||
| subtype | No | ||
| fortrade | No | ||
| hasparts | No | ||
| maxplays | No | ||
| minplays | No | ||
| username | Yes | BGG username. When the user refers to themselves, use 'SELF'. | |
| wishlist | No | ||
| maxrating | No | ||
| minrating | No | ||
| wanttobuy | No | ||
| preordered | No | ||
| wanttoplay | No | ||
| maxbggrating | No | ||
| minbggrating | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It successfully indicates default behavior (returns all matching games) and enumerates return fields (name, ID, rating, plays, status), providing useful output transparency. However, it lacks operational details such as rate limiting, caching behavior, or authentication requirements.
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 consists of three concise sentences totaling under 40 words, with the purpose clearly stated in the opening sentence. While efficiently structured and front-loaded, the third sentence ('Use the filter parameters...') is too vague to fully earn its place given the complexity of the filtering options available.
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 17 parameters with minimal schema documentation and no output schema, the description is incomplete regarding parameter semantics. While it partially compensates by describing the return values (name, ID, rating, plays, status), it leaves the majority of the filtering capability unexplained and provides no guidance on error conditions or edge 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 only 6%, leaving 16 of 17 parameters undocumented in the schema. The description mentions 'filter parameters' broadly but fails to explain the semantics of critical filters like owned, wishlist, rated, or the rating range parameters (minrating, maxrating). Given the severe schema coverage gap, the description provides inadequate compensatory 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 provides a specific verb ('Query') and resource ('user's board game collection'), clearly distinguishing it from sibling tools like bgg-search (general game search) and bgg-user (user profile data). However, it does not explicitly differentiate from bgg-details, which retrieves specific game information rather than collection lists.
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 mentions 'Use the filter parameters to narrow results,' which hints at functionality but provides no explicit guidance on when to use this tool versus alternatives like bgg-search or bgg-user. It fails to specify prerequisites (such as requiring a valid public BGG username) or scenarios where this tool would be inappropriate.
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 board games on BoardGameGeek (BGG) including description, mechanics, categories, player count, playtime, complexity, and ratings. Use this tool to deep dive into games found via other tools (e.g. after getting collection results or search results that only return basic info). Use 'name' for a single game lookup by name, 'id' for a single game lookup by BGG ID, or 'ids' to fetch multiple games at once (up to 20). Only provide one of these parameters.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | The BoardGameGeek ID of a single board game. | |
| ids | No | Array of BoardGameGeek IDs for fetching multiple games (max 20). | |
| name | No | The name of the board game to look up. |
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 mutual exclusivity constraint (crucial behavioral rule), the batch limit of 20 games, and enumerates return fields (description, mechanics, etc.) to compensate for the missing output schema. Minor gap on rate limits or authentication requirements.
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?
Four sentences with zero waste: (1) capability and return fields, (2) contextual usage vs siblings, (3) parameter selection guidance, (4) mutual exclusivity constraint. Information is front-loaded and logically sequenced from 'what' to 'when' to 'how.'
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 3-parameter lookup tool with 100% schema coverage and no output schema, the description adequately compensates by listing return fields and explaining the single-vs-batch lookup patterns. Would benefit from explicit mention of error handling or rate limiting to achieve a 5.
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?
While input schema has 100% description coverage (baseline 3), the description adds significant value by clarifying the mutual exclusivity rule ('Only provide one') and mapping usage patterns ('Use 'name' for a single game lookup... 'ids' to fetch multiple games'). This contextual guidance prevents invocation errors.
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 ('Get detailed information') and resource ('board games on BoardGameGeek'), listing specific data fields returned (mechanics, categories, ratings, etc.). It clearly distinguishes from siblings by positioning this as a 'deep dive' tool to use after 'search results that only return basic info.'
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?
Explicitly states when to use ('to deep dive into games found via other tools'), gives concrete examples ('after getting collection results or search results'), and mandates critical constraints ('Only provide one of these parameters'). It effectively maps the workflow across the tool family.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find the current trending board game hotness on BoardGameGeek (BGG)
| 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 of behavioral disclosure. While 'Find' implies a read-only operation, the description fails to disclose what data structure is returned (list of games, rankings, IDs), quantity limits, or rate limiting concerns.
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 consists of a single, efficient sentence that immediately conveys the tool's function without redundancy or filler. 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?
Given the absence of parameters, the description adequately covers inputs. However, with no output schema provided, the description should ideally characterize the returned data (e.g., 'returns ranked list of trending games') to be complete. As is, it is minimally viable but leaves usage gaps.
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 contains zero parameters. Per evaluation rules, 0 parameters establishes a baseline score of 4.
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 ('Find') and clearly identifies the resource ('current trending board game hotness on BoardGameGeek'). However, it does not explicitly distinguish this discovery-oriented tool from siblings like 'bgg-search' (find specific games) or 'bgg-recommender'.
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 indicate whether to use this for discovery versus searching for specific titles, nor does it mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get current prices for board games from multiple retailers using BGG IDs
| Name | Required | Description | Default |
|---|---|---|---|
| ids | Yes | Comma-separated BGG IDs (e.g., '12,844,2096,13857') | |
| currency | No | Currency code (default: USD) | |
| destination | No | Destination country (default: US) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Adds 'current' (implies real-time data) and 'multiple retailers' (indicates aggregated sources), but lacks disclosure on error behavior (invalid IDs), rate limits, caching behavior, or authentication requirements. Safe but incomplete behavioral coverage.
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?
Single sentence with zero waste. Front-loaded with action verb, immediately identifies domain (board games), scope (current prices), sources (multiple retailers), and critical input constraint (BGG IDs). Every phrase 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?
Appropriate for a 3-parameter retrieval tool with 100% schema coverage. Absence of output schema is acceptable given the intuitive return type (price data), though explicit mention of return structure (e.g., 'returns price data per retailer') would strengthen completeness. Adequate for tool complexity.
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%, establishing baseline 3. Description mentions 'BGG IDs' which aligns with the 'ids' parameter, but adds no additional semantic context for 'currency' or 'destination' beyond what the schema already documents. No clarification on why destination matters for pricing.
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?
Description provides specific verb ('Get'), clear resource ('current prices for board games'), data source ('multiple retailers'), and key input requirement ('using BGG IDs'). Clearly distinguishes from siblings like bgg-search, bgg-details, and bgg-collection by focusing exclusively on commercial pricing data.
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?
Implies prerequisite of having BGG IDs ('using BGG IDs'), suggesting users need IDs beforehand, but does not explicitly state when to use this vs. bgg-search (to find IDs) or clarify workflow. No explicit 'when-not-to-use' or alternative guidance provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get game recommendations similar to a specific board game. Provide either 'name' or 'id', not both.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | BGG ID of the game to base recommendations on. | |
| name | No | Name of the game to base recommendations on. | |
| min_votes | No | Minimum votes threshold (default: 30) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but only reveals the input mutual exclusivity constraint. It fails to disclose output format (what fields are returned?), similarity methodology, read-only status, or the impact of min_votes on result quality.
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 zero waste: the first establishes purpose immediately, and the second provides the essential constraint. No fluff or redundant information.
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 lack of output schema and annotations, the description adequately covers the input requirements but leaves significant gaps regarding return value structure, recommendation ranking logic, and error conditions (e.g., what happens if neither name nor id is provided?).
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?
While the schema has 100% description coverage (baseline 3), the description adds critical semantic information not present in the schema: the mutual exclusivity constraint between 'name' and 'id' parameters, which prevents invalid invocation patterns.
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 game recommendations'), resource ('board game'), and relationship ('similar to'), effectively distinguishing it from sibling tools like bgg-search (which finds by query) and bgg-details (which retrieves specific game data).
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 an important constraint ('Provide either 'name' or 'id', not both'), but lacks explicit guidance on when to prefer this tool over alternatives like bgg-search or bgg-hot for discovery use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search BoardGameGeek rules forums to find answers and clarifications from the community. Use when users ask rules questions about board games.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | The BGG ID of the board game. | |
| name | No | The name of the board game. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It successfully discloses the community-sourced nature of the data ('from the community'), but omits behavioral details like rate limits, search fuzziness, or how it handles the optional ID vs name parameters (both are optional per schema, but the description doesn't clarify usage patterns).
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 consists of exactly two efficient sentences with zero waste: the first establishes purpose, the second establishes usage context. It is appropriately front-loaded and sized for the tool's complexity.
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 straightforward purpose and complete input schema, the description adequately covers the primary use case. It could be improved by clarifying the optional parameter relationship (ID vs name) or describing the return format (forum threads vs posts), but it is sufficient for agent selection.
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%, providing the baseline score of 3. The description does not add semantic context beyond the schema (e.g., explaining that both parameters are optional or when to prefer ID over name), but it doesn't need to compensate for missing schema 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 provides a specific verb ('Search'), resource ('BoardGameGeek rules forums'), and outcome ('find answers and clarifications from the community'). It clearly distinguishes this from siblings like bgg-search (general) and bgg-details (game metadata) by specifying the 'rules forums' scope.
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 includes explicit positive guidance ('Use when users ask rules questions about board games'). However, it lacks negative guidance or explicit alternatives (e.g., when to use bgg-details instead for official rulebooks vs community interpretations).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for board games on BoardGameGeek (BGG) by name or part of a name using a broad search
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Filter by game type (default: all) | |
| limit | No | Max results (default: 30) | |
| query | Yes | Game name to search for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. The phrase 'broad search' adds valuable behavioral context indicating non-exact matching and potentially large result sets. However, it omits return format details, rate limiting, or pagination behavior that would help the agent process results.
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?
Single, efficiently constructed sentence with no filler. Front-loaded with the core action ('Search for'), followed by resource, parameter usage, and behavioral characteristic ('broad search'). Every clause 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?
Adequate for a simple 3-parameter search tool with no output schema, but misses opportunity to describe return values (e.g., 'returns list of games with IDs suitable for bgg-details') which would enable better tool chaining with siblings. Meets minimum viable standard.
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 100%, establishing a baseline of 3. The description adds the 'part of a name' nuance for the query parameter, which expands slightly on the schema's 'Game name to search for'. It doesn't add significant detail about the 'type' or 'limit' parameters beyond what's 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?
Clearly states the action ('Search for'), resource ('board games on BoardGameGeek'), and input method ('by name or part of a name'). However, it does not explicitly distinguish from sibling tools like bgg-details (which likely requires a specific game ID rather than a search term).
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?
Implies usage through 'by name or part of a name' and 'broad search', suggesting it's for fuzzy matching when the exact game isn't known. Lacks explicit guidance on when to use bgg-details instead (e.g., 'use this when you don't know the game ID').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get full content of a specific BoardGameGeek forum thread, including all posts and replies. Use this after finding relevant threads with bgg-rules.
| Name | Required | Description | Default |
|---|---|---|---|
| thread_id | Yes | The BoardGameGeek thread ID to fetch |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses scope behavior ('full content... all posts and replies') indicating a comprehensive fetch rather than summary. However, it lacks disclosure of read-only safety, rate limits, pagination behavior for long threads, or error handling when thread_id is invalid.
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 total, front-loaded with the action verb. First sentence establishes purpose and scope; second provides workflow context. No redundant or filler content—every word serves the selection decision.
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 retrieval tool with simple input structure and no output schema, the description adequately covers the invocation context by mentioning the return content type (posts/replies) and workflow position. Could be improved by hinting at output structure or size limits, but sufficient for the 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?
Schema coverage is 100% with thread_id already described as 'The BoardGameGeek thread ID to fetch'. The description references 'specific... thread' which aligns with the parameter but adds no additional syntax, format examples, or constraints beyond the schema definition. Baseline 3 appropriate 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 uses specific verb 'Get' with clear resource 'BoardGameGeek forum thread' and scope 'full content... including all posts and replies'. It distinguishes from sibling search tools by specifying this retrieves content of a specific thread ID rather than searching or listing.
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?
Explicitly states workflow dependency: 'Use this after finding relevant threads with bgg-rules.' This provides clear guidance on when to invoke the tool relative to its sibling bgg-rules, establishing the correct sequence for forum thread analysis.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find what games user1 owns that user2 has on their wishlist. Shows potential trading opportunities.
| Name | Required | Description | Default |
|---|---|---|---|
| user1 | Yes | BGG username whose collection will be checked. Use 'SELF' for yourself. | |
| user2 | Yes | BGG username whose wishlist will be checked against user1's collection |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It explains the matching logic (owns vs wishlist) but fails to disclose read-only status, error handling (invalid usernames), or return format (list of game IDs vs full details).
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 efficient sentences with zero waste. The first states the core function immediately; the second states the value proposition. 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?
Given 100% schema coverage and no output schema, the description adequately covers the input contract. However, it could briefly mention the return structure (e.g., 'returns matching game titles') since no output schema exists to document the response format.
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%, establishing a baseline of 3. The description reinforces the directional relationship (user1's collection vs user2's wishlist) but does not add syntax details, validation rules, or emphasize the 'SELF' convention beyond what the schema already provides.
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 specific verbs ('Find') and clearly identifies the resource (games user1 owns vs user2's wishlist). It distinguishes itself from siblings like bgg-collection (simple lookup) and bgg-search by explicitly targeting cross-user trade matching.
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 'Shows potential trading opportunities' implies the use case, but there is no explicit guidance on when to use this versus bgg-collection (e.g., 'Use this when you want to find trades between two specific users rather than viewing a single collection').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find details about a specific user on BoardGameGeek (BGG)
| Name | Required | Description | Default |
|---|---|---|---|
| username | Yes | BGG username. When the user refers to themselves, use 'SELF'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Fails to disclose error behavior (what happens if user doesn't exist?), rate limits, authentication requirements, or whether the operation is idempotent. 'Find' implies read-only but doesn't confirm safety explicitly.
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?
Single sentence, front-loaded with verb and resource. No redundant phrases or structural waste. Appropriate length for a simple single-parameter tool.
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 simplicity (1 parameter, no nested objects), the description is minimally sufficient but leaves gaps. Without an output schema, it fails to hint at the return structure (JSON object? XML? specific fields like 'firstname', 'lastlogin'?), which would help the agent understand if this meets its information needs.
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 100%, so the parameter is fully documented in structured form. Description mentions 'specific user' which loosely maps to the username parameter but adds no semantic value beyond the schema's explanation. Baseline 3 appropriate when schema does the heavy lifting.
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 the resource (BGG user) and general action ('Find'), but uses vague terminology. 'Find' ambiguously suggests search (conflicting with sibling bgg-search) rather than retrieval, and 'details' fails to specify what data is returned (profile, stats, preferences?). Lacks scope specificity.
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 guidance on when to use this versus siblings like bgg-collection (which also returns user-associated data) or bgg-search. No mention of prerequisites like username format or visibility restrictions. The 'SELF' keyword hint exists only in the schema, not the description.
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.
bgg-collection18 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / properties / fortrade / descriptionRemoved value: -"Filters for games that are marked for trade in the collection"Input schema / properties / hasparts / descriptionRemoved value: -"Filters for games that have spare parts or not in the collection"Input schema / properties / maxbggrating / descriptionRemoved value: -"Filters based on the maximum global BoardGameGeek (BGG) rating of the games in the collection"Input schema / properties / maxplays / descriptionRemoved value: -"Filters based on the maximum number of plays of the games in the collection"Input schema / properties / maxrating / descriptionRemoved value: -"Filters based on the maximum personal rating of the games in the collection"Input schema / properties / minbggrating / descriptionRemoved value: -"Filters based on the minimum global BoardGameGeek (BGG) rating of the games in the collection"Input schema / properties / minplays / descriptionRemoved value: -"Filters based on the minimum number of plays of the games in the collection"Input schema / properties / minrating / descriptionRemoved value: -"Filters based on the minimum personal rating of the games in the collection"Input schema / properties / owned / descriptionRemoved value: -"Filters for owned games in the collection (default: true if no ownership filters specified)"Input schema / properties / played / descriptionRemoved value: -"Filters for games that have recorded plays in the collection"Input schema / properties / preordered / descriptionRemoved value: -"Filters for preordered games in the collection"Input schema / properties / rated / descriptionRemoved value: -"Filters for games that are rated in the collection"Input schema / properties / subtype / descriptionRemoved value: -"Filter by game type: 'boardgame' for base games only (excludes expansions), 'boardgameexpansion' for expansions only"Input schema / properties / username / descriptionPrevious value: -"The username of the BoardGameGeek (BGG) user who owns the collection. When the user refers to themselves (me, my, I), use 'SELF' as the value."New value: +"BGG username. When the user refers to themselves, use 'SELF'."Input schema / properties / wanttobuy / descriptionRemoved value: -"Filters for games that the user wants to buy in the collection"Input schema / properties / wanttoplay / descriptionRemoved value: -"Filters for games that the user wants to play in the collection"Input schema / properties / wishlist / descriptionRemoved value: -"Filters for wishlisted games in the collection"bgg-details6 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / properties / full_detailsRemoved value: -{
- "description": "Return the complete BGG API response instead of essential info. WARNING: This returns significantly more data and can overload AI context windows. ONLY set this to true if the user explicitly requests 'full details', 'complete data', or similar. Default behavior returns essential info which is sufficient for most use cases.",
- "type": "boolean"
-}Input schema / properties / id / descriptionPrevious value: -"The BoardGameGeek ID of the board game"New value: +"The BoardGameGeek ID of a single board game."Input schema / properties / ids / descriptionPrevious value: -"Array of BoardGameGeek IDs to get details for multiple games at once (maximum 20 IDs per request)"New value: +"Array of BoardGameGeek IDs for fetching multiple games (max 20)."Input schema / properties / ids / itemsAdded value: +{
+ "type": "number"
+}Input schema / properties / name / descriptionPrevious value: -"The name of the board game"New value: +"The name of the board game to look up."bgg-hot2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / propertiesAdded value: +{}bgg-price5 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / properties / currency / descriptionPrevious value: -"Currency code: DKK, GBP, SEK, EUR, or USD (default: USD)"New value: +"Currency code (default: USD)"Input schema / properties / currency / enumAdded value: +[
+ "DKK",
+ "GBP",
+ "SEK",
+ "EUR",
+ "USD"
+]Input schema / properties / destination / descriptionPrevious value: -"Destination country: DK, SE, GB, DE, or US (default: US)"New value: +"Destination country (default: US)"Input schema / properties / destination / enumAdded value: +[
+ "DK",
+ "SE",
+ "GB",
+ "DE",
+ "US"
+]bgg-recommender5 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / properties / id / descriptionPrevious value: -"BoardGameGeek (BGG) ID of the game to base recommendations on (preferred for speed)"New value: +"BGG ID of the game to base recommendations on."Input schema / properties / id / typePrevious value: -"string"New value: +"number"Input schema / properties / min_votes / descriptionPrevious value: -"Minimum votes threshold for recommendation quality (default: 30)"New value: +"Minimum votes threshold (default: 30)"Input schema / properties / name / descriptionPrevious value: -"Name of the game to base recommendations on (slower than using ID)"New value: +"Name of the game to base recommendations on."bgg-rules3 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / properties / id / descriptionPrevious value: -"The BoardGameGeek ID of the board game"New value: +"The BGG ID of the board game."Input schema / properties / name / descriptionPrevious value: -"The name of the board game"New value: +"The name of the board game."bgg-search4 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / properties / limit / descriptionPrevious value: -"Maximum number of results to return (default: 30)"New value: +"Max results (default: 30)"Input schema / properties / query / descriptionPrevious value: -"Game name to search for on BoardGameGeek (BGG)"New value: +"Game name to search for"Input schema / properties / type / descriptionPrevious value: -"Filter by type (default: all, options: 'boardgame' (aka base game), 'boardgameexpansion', or 'all')"New value: +"Filter by game type (default: all)"bgg-thread-details1 field changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"bgg-trade-finder2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / properties / user1 / descriptionPrevious value: -"BGG username whose collection will be checked. When the user refers to themselves (me, my, I), use 'SELF' as the value."New value: +"BGG username whose collection will be checked. Use 'SELF' for yourself."bgg-user2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / properties / username / descriptionPrevious value: -"The username of the BoardGameGeek (BGG) user. When the user refers to themselves (me, my, I), use 'SELF' as the value."New value: +"BGG username. When the user refers to themselves, use 'SELF'."bgg-collectionbgg-detailsbgg-hotbgg-pricebgg-recommenderbgg-rulesbgg-searchbgg-thread-detailsbgg-trade-finderbgg-userBoardgames MCP — wraps Board Game Atlas API (public demo client_id, free)
TheGamesDB MCP — wraps TheGamesDB API (thegamesdb.net), a community
RAWG MCP — wraps the RAWG video games database API (rawg.io)
Videogames MCP — wraps Free-to-Play Games API (freetogame.com, free, no auth)
Add one secure layer between your agents and this server.