Skip to main content
Glama
Sign In
Crawlora-org

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

cardmarket_price_guide

Fetches paginated Cardmarket daily price-guide data for games or accessories, enabling product price lookup by game ID or product ID. Returns category IDs without labels and marks display permission as unconfirmed.

Instructions

Get Cardmarket daily price-guide data. Returns a paginated snapshot of Cardmarket's public daily price-guide export. The response discovers category IDs but the source file has no category labels. Cardmarket's posted English terms include a prior-written-agreement clause for external price display in a future-dated revision whose effective status is unconfirmed here; the response marks permission as unconfirmed.

Input Schema

NameRequiredDescriptionDefault
kindNoPrice-guide dataset; defaults to game
limitNoRows per page, 1-500; defaults to 100
offsetNoZero-based offset; defaults to 0
game_idNoRequired when kind=game; omit for global accessories
product_idNoOptional exact product ID filter
category_idNoOptional category ID; discover the full set with /cardmarket/price-guide/categories

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.18

TDQS

A3.5/5.0
Behavior4/5

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

With no annotations, the description carries the behavioral burden and adds meaningful context: it says this is a public paginated export, warns that category labels are missing, and notes that the response marks external-display permission as unconfirmed. It does not cover auth, rate limits, or explicit read-only safety, so it is strong but not complete.

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 key purpose is front-loaded in the first sentence, and the remaining sentences add relevant data limitations and permission caveats. The legal-terms sentence is dense and somewhat convoluted, but it is not excessive for a tool with no annotations and a non-obvious licensing caveat.

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 read-only data-retrieval tool with a fully described input schema and no output schema, the description covers the source, pagination, missing category labels, and permission uncertainty. It could say more about the shape of price-guide rows, but it gives enough context to select and invoke the tool safely.

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%, so the schema already documents all six parameters, including the conditional game_id requirement and category discovery hint. The description adds no parameter-level details beyond saying the output is paginated, so the baseline 3 is appropriate.

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 uses a specific verb and resource: 'Get Cardmarket daily price-guide data' and calls it a paginated export snapshot. It is clear what the tool returns, but it does not explicitly distinguish this from sibling tools such as cardmarket_price_guide_categories or cardmarket_catalog.

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?

There is no explicit statement of when to use this tool, when not to use it, or which sibling to call instead. The closest signal is implied by the purpose itself, plus the note that category IDs appear without labels, but the description gives no routing guidance.

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