Boardgames MCP — wraps Board Game Atlas API (public demo client_id, free)
Three tools with clear verb-noun naming (search_games, get_game, hot_games) and complete input schemas. Descriptions are present and reasonably detailed (120-180 chars), exceeding the 10-char minimum. All parameters have type definitions and descriptions. However, output schemas are not documented, LLMs cannot see what fields to expect from responses. Parameter descriptions lack explicit constraints (e.g., 'limit: 1 - 100' is stated but not formalized). No error handling guidance or recovery paths documented. Missing idempotency hints and chaining field documentation.
Get full details for a specific board game by its Board Game Atlas ID. Returns name, year, player count, playtime, description, rating, publisher, designer, and price.
Get the most popular board games right now, ordered by popularity rank. Returns name, year, player count, playtime, rating, and rank.
Search for board games by name using Board Game Atlas. Returns name, year, player count, playtime, rating, price, and a short description.
Output schemas not documented. LLMs cannot see what fields formatGame() returns (id, name, year_published, etc.). Without documented return types, agents cannot plan downstream operations or extract required data.
No error handling guidance. If Board Game Atlas API returns 404 or rate limit, the generic 'Board Game Atlas API error: {status}' tells the LLM nothing about recovery. Should specify: is this retryable? Should the user be asked for clarification?
Parameter constraints stated in prose but not formalized. 'limit: 1 - 100, default 10' is readable but not machine-parseable. JSON Schema should include minimum, maximum, and default fields.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 58 | 2026-07-28+ | v2 |
No pagination or result-limiting guidance in descriptions. search_games and hot_games return arrays but do not document max result count or whether pagination is supported. Large result sets risk context window exhaustion.
Missing chaining field documentation. If an agent calls search_games and then get_game, the response must include the 'id' field (which it does via formatGame). However, this is not explicitly documented, forcing LLMs to infer the chain.