Skip to main content
Glama
Crawlora MCP

Crawlora MCP

Official

boardgamegeek_entity

Fetch a BoardGameGeek family, person, company, property, or version by type and ID to retrieve names, descriptions, images, website, and linked credits or members.

Instructions

Get a BoardGameGeek family, person, company, property or version. Returns one non-game entity by canonical object type and numeric id: name, alternate names, description and wiki text, website, images, and the typed link map for that entity (for example a designer's credits, a publisher's games, a family's members, a category's games, or a version's parent game and publishers). Community counters and the item's field schema are merged in. Slug aliases are not accepted because they return item records without description content.

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": {
      "type": "<type>",
      "id": "<id>"
    },
    "name": "boardgamegeek_entity"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYesBoardGameGeek entity id, positive integer; the Catan family is 3
typeYesEntity object type

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.20

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations at all, the description carries the full disclosure burden and does so well: it enumerates the returned payload (names, descriptions, wiki text, website, images, typed link map) and notes that community counters and the item's field schema are merged in, so the agent knows what to expect. It omits non-behavioral operational facts such as auth requirements or rate limits, which is a minor gap rather than a misleading one.

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

Conciseness3/5

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

The identification of the resource is front-loaded, but the second sentence is a long, comma-chained enumeration that mixes return fields, per-type link meanings, and merge behavior. It is dense and useful, yet could be split for scanability without losing content.

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?

With no output schema and no annotations, the description must describe what comes back, and it covers the entity payload and link map in enough detail for an agent to decide to call it. Missing operational details (auth, pagination, error behavior on invalid ids) keep it from being fully complete.

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

Parameters4/5

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

Schema coverage is already 100%, so the baseline would be 3, but the description adds real meaning by clarifying that ids must be canonical numeric ids and that slug aliases are rejected, plus it spells out the 'typed link map' semantics per entity type. That is information the schema alone does not convey.

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

Purpose5/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 a BoardGameGeek family, person, company, property or version') and immediately scopes it as 'one non-game entity by canonical object type and numeric id,' which cleanly separates it from a game-lookup sibling in the same namespace.

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

Usage Guidelines4/5

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

It establishes clear context through the 'non-game entity' framing and adds an explicit exclusion ('Slug aliases are not accepted because they return item records without description content'), which steers the agent away from a wrong input form. It stops short of naming an alternate tool for cases where the caller actually wants a game record.

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