Crawlora MCP

Official

Overview Schema Source Related Servers Discussions Admin

boardgamegeek_media

List a BoardGameGeek item's images, videos, or files with captions, hosts, sizes, and language details, plus filters for sort order, gallery type, license, and date interval.

Instructions

List a BoardGameGeek item's images, videos or files. Returns one page of media for one item: gallery images with captions and vote counts, videos with host, title, duration and thumbnail, or file pages with filename, size and language. Exactly one of images, videos or files is populated. Filters follow the source's own per-kind filter models: images accept sort, interval, gallery, tag and license; videos accept sort, gallery and languageid; files accept sort and languageid. A filter used with the wrong kind is rejected locally with HTTP 400.

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

Input Schema

Name	Required	Description
`id`	Yes	BoardGameGeek item (thing) id, positive integer; Catan is 13
`tag`	No	Image category; image only
`sort`	No	Sort order; applies to images, videos and files
`type`	No	Media kind; defaults to image
`pageid`	No	Page number, 1-1000
`gallery`	No	Gallery filter. Images: all, game, person, creative. Videos: all, review, session, instructional, interview, unboxing, humor, other. Not valid for files.
`license`	No	Image license filter; image only
`interval`	No	Image date interval; image only
`showcount`	No	Page size, 1-50
`languageid`	No	Media language id from boardgamegeek_taxonomy media_video_languages/media_file_languages; video and file only

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.17.20Nov 12, 2026

TDQS

A3.8/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and does substantial work: it discloses pagination ('one page of media'), mutual exclusivity of the three kind payloads, the per-kind filter model, and a concrete failure mode (wrong-kind filter rejected locally with HTTP 400). It also describes the return payload fields for each kind, compensating for the absent output schema. Gaps remain around authentication, rate limits, and defaults for pageid/showcount, which is why it is not a 5.

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?

The description is front-loaded with purpose, then return shape, then filter rules and failure behavior, so the most decision-relevant information comes first. Sentences are dense and mostly earn their place, though the per-kind filter enumeration partially repeats what the schema already encodes. No filler or marketing language is present.

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 10-parameter read tool with no annotations and no output schema, the description covers the two things an agent most needs: what comes back per kind and what happens on invalid filter/kind combinations. Combined with the fully documented schema, an agent can call it correctly without further context. Missing auth/prerequisite notes and default values 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 description coverage is 100%, so the baseline is 3, but the description adds real meaning beyond it by grouping filters by media kind (images: sort/interval/gallery/tag/license; videos: sort/gallery/languageid; files: sort/languageid) and stating the consequence of misuse (local HTTP 400). That mapping and error semantics are not spelled out as a whole in the schema, which only marks individual params as 'image only' or 'video and file only'. Defaults for showcount and pageid are still left unstated.

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 opening sentence gives a specific verb and resource ('List a BoardGameGeek item's images, videos or files') and immediately scopes it to one item and one page. The three media kinds are enumerated with their returned fields, so an agent knows exactly what the tool produces. It stops short of naming any sibling tool (e.g. boardgamegeek_game or boardgamegeek_entity) to contrast against, so differentiation must be inferred from the name.

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: the agent can infer it should use this when it needs media for a known item id, and the per-kind filter rules imply which parameters to pick. However, there is no explicit when-to-use/when-not-to-use statement and no reference to the sibling tools that also return media-adjacent content. The wrong-kind rejection note is the closest thing to selection guidance, and it is about parameters rather than tool choice.

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

Deploy Server