Crawlora MCP

Official

Overview Schema Source Related Servers Discussions Admin

hearthstone_cards

List and filter Hearthstone cards by class, set, mana, rarity, type, and game mode, with discoverable filter values for precise card-gallery results.

Instructions

List Hearthstone cards. Returns a card-gallery page with native constructed, Battlegrounds, Mercenaries, and card-back filters. Dynamic filter values are discoverable from hearthstone_filters; sort mappings are returned there as well. The default view is all-class Standard with page size 450.

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": "hearthstone_cards"
  }
}

Input Schema

Name	Required	Description
`set`	No	Source set selector; use hearthstone_filters to discover current sets
`page`	No	Upstream page number
`sort`	No	Native source sort expression; see sort_options from hearthstone_filters
`tier`	No	Repeatable Battlegrounds tavern-tier filter
`type`	No	Repeatable source type filter; see hearthstone_filters
`armor`	No	Repeatable armor filter
`class`	No	Source class selector; use hearthstone_filters to discover current classes
`order`	No	Source sort direction
`attack`	No	Repeatable attack filter
`health`	No	Repeatable health filter
`locale`	No	Source card locale; defaults to en_US
`rarity`	No	Source rarity filter; see hearthstone_filters
`faction`	No	Source faction filter; see hearthstone_filters
`keyword`	No	Source keyword filter; see hearthstone_filters
`deckcode`	No	Optional source deck code filter
`gameMode`	No	Source game mode; Arena and Duels select their matching set
`manaCost`	No	Repeatable mana-cost filter
`pageSize`	No	Upstream page size
`rarityId`	No	Repeatable rarity ID filter
`viewMode`	No	Card-gallery view mode
`cardSetId`	No	Repeatable card-set ID filter
`bgCardType`	No	Battlegrounds card-type selector from the source gallery
`bgGameMode`	No	Battlegrounds mode filter; see hearthstone_filters
`cardTypeId`	No	Repeatable card-type ID filter
`deckFormat`	No	Source deck-format selector
`minionType`	No	Source minion-type filter; see hearthstone_filters
`textFilter`	No	Source card text search
`zilliaxMod`	No	Source Zilliax module filter
`collectible`	No	Repeatable source collectible selector
`spellSchool`	No	Source spell-school filter; see hearthstone_filters
`filterLocale`	No	Locale for textFilter; defaults to en-us
`mercenaryRole`	No	Source Mercenary role filter; see hearthstone_filters
`spellSchoolId`	No	Repeatable spell-school ID filter
`cardBackCategory`	No	Source card-back category filter; see hearthstone_filters
`mercenaryFaction`	No	Source Mercenary faction filter; see hearthstone_filters

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.17.20Nov 12, 2026

TDQS

A3.5/5.0

Behavior3/5

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

With no annotations, the description must carry the full behavioral burden, and it does disclose the useful default state ('all-class Standard with page size 450') and that the result is a gallery-style page. It says nothing about pagination semantics beyond the existence of page/pageSize, total-count behavior, result size, or error conditions, so meaningful gaps remain for a 35-parameter tool.

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?

Four sentences, front-loaded with purpose, then return shape, then the dependency pointer, then the default view. Nothing is padding, though the default-view sentence and the filter-discovery sentence could be merged without losing information.

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 no-annotation, no-output-schema tool with 35 optional parameters, the description covers purpose, return shape, where to get valid filter values, and the default invocation state. The remaining gap is pagination/total-count behavior, which is minor given the schema fully documents each parameter.

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 every one of the 35 parameters is already documented in the schema, and most schema descriptions already point at the filters tool for valid values. The description adds only two defaults (page size 450, all-class Standard) and otherwise restates the schema's own pointer to the filter tool, 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?

The description opens with a specific verb+resource ('List Hearthstone cards') and adds that it returns a card-gallery page across constructed, Battlegrounds, Mercenaries, and card-back views, which is far more than the name alone conveys. It does not explicitly distinguish itself from the singular sibling hearthstone_card, and it directs agents to a tool named 'hearthstone_filters' rather than the sibling name 'hearthstone_card_filters', which slightly muddies routing.

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?

It gives real workflow guidance: dynamic filter values are discoverable from the filters tool and sort mappings are returned there, implying a discover-then-list sequence. However, it never states when NOT to use this tool (e.g., to fetch a single card by id) and offers no prerequisites or exclusions.

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

Deploy Server