Crawlora MCP

Official

Overview Schema Source Related Servers Discussions Admin

boardgamegeek_hotness

Fetch BoardGameGeek's current hotness list for games, people, or companies, with rank positions, rank changes, and details to track trending board game topics.

Instructions

Get BoardGameGeek's current hotness list. Returns the site's ranked hotness list for one object type: games (thing), people or companies, with the object identifier, name, rank position, rank delta since the previous day, year published (games only), short description (games only) and images. The list length is requested with showcount; the source caps it at 50.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "boardgamegeek_hotness"
  }
}

Input Schema

Name	Required	Description	Default
`showcount`	No	Requested list length, 1-50; the source caps the list at 50
`objecttype`	No	Object type; one of thing (games), person or company

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.17.20Nov 12, 2026

TDQS

A3.7/5.0

Behavior4/5

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

With no annotations and no output schema, the description carries the full disclosure burden and does reasonably well: it says the result is a ranked list, what fields each entry carries (identifier, name, rank, rank delta since previous day, year/description for games only, images), and that the source caps the list at 50. It omits rate limits, auth needs, and default values when parameters are omitted.

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?

Three sentences, front-loaded with the core action, then return shape, then the size constraint. The middle sentence is long but every clause adds return-value information that has no other home since there is no output schema.

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

Completeness4/5

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

For a simple two-optional-parameter read tool with no output schema, the description covers purpose, return fields, and the size cap adequately. The remaining gap is default behavior (list length and object type when omitted), which an agent must guess.

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 coverage is 100%, so both parameters are already documented, including the enum for objecttype. The description only restates the 50-item cap and the thing/person/company mapping, adding marginal value; it does not state defaults or behavior when parameters are omitted.

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?

The description opens with a specific verb and resource: 'Get BoardGameGeek's current hotness list,' and clarifies it covers exactly one object type per call. It is clearly distinct from generic entity/game lookups by naming the 'ranked hotness list' concept, but it never explicitly contrasts itself with siblings like boardgamegeek_game or boardgamegeek_entity.

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

Usage Guidelines3/5

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

Usage is implied rather than stated: an agent can infer this is the tool for trending/popular items, and the phrase 'one object type' hints that separate calls are needed for games vs people vs companies. There is no explicit when-to-use/when-not-to-use guidance or named alternative for individual-entity lookups.

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

Deploy Server