Skip to main content
Glama
Sign In
UnClick MCP Server

UnClick MCP Server

by malamutemayhem
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

bgg_game_reviews

Read-onlyIdempotent

Retrieve paginated BoardGameGeek user comments and ratings for a board game by game ID to assess player feedback.

Instructions

Get user comments and ratings for a board game on BGG.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "gameId": "<gameId>"
    },
    "name": "bgg_game_reviews"
  }
}

Input Schema

NameRequiredDescriptionDefault
pageNoPage number (default 1, 25 comments per page)
gameIdYesBoardGameGeek game ID

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.1.5

TDQS

B3.2/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds that the payload is comments and ratings, which tells the agent what kind of data comes back. It says nothing about pagination limits or ordering, though the schema covers the page size.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence with no waste. It is appropriately sized for a simple two-parameter read tool, though it leaves room unused for a scoping clause.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only, no-output-schema tool this is minimally adequate: the agent knows it fetches reviews and can page through them. It lacks detail on result ordering, how ratings are summarized, and whether pagination ends, which would help an agent plan calls.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with both gameId and the page parameter (25 comments per page) documented in the schema. The description adds no parameter-level meaning beyond that, so the baseline 3 applies.

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

Purpose4/5

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

States a specific verb and resource ('Get user comments and ratings for a board game on BGG'), making the content type clear. It does not explicitly differentiate itself from siblings like bgg_game_details (which presumably returns metadata, not reviews), so an agent must infer the split.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No when-to-use or when-not guidance is given. The sibling set includes bgg_game_details and bgg_user_collection, and the description never says to pick this tool for community reviews versus those for facts or collections.

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

Deploy Server

Other Tools