cardmarket-mcp

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

Annotations already declare read-only and open-world behavior, and the description adds useful context beyond them: results are cheapest first, include seller/country/condition/language/foil/quantity plus price distribution stats, and require the caller's own Cardmarket credentials. It does not disclose rate limits or pagination behavior, but the added auth and ordering details are substantive.

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

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

The description is front-loaded and efficient: the first sentence states the core listing behavior and returned fields, the second covers filters, and the third covers credentials and read-only status. There is little wasted text for the amount of useful information provided.

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

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

With no output schema, the description helpfully lists the main returned fields and price-distribution stats, and it discloses the credential requirement. The main remaining gap is the unmentioned limit behavior and minimal explanation of the userType parameter, but the definition is otherwise complete enough to call correctly.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning. It covers several filters (min condition, language id, foil, seller type) and repeats the condition enum values, but it omits the limit parameter entirely and does not explain the userType enum values beyond 'seller type'.

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

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: it lists current offers for a Cardmarket product, sorted cheapest first, and includes seller and price-distribution details. It is clear what the tool does, but it does not explicitly differentiate itself from siblings such as cardmarket_seller_stock or cardmarket_price_guide.

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

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

The optional filters imply usage for narrowing seller offers, and the credential requirement gives important setup context. However, there is no explicit guidance on when to use this versus cardmarket_price_guide or cardmarket_seller_stock, nor any stated exclusions.

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

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

Annotations already declare readOnlyHint=true, so 'Read-only' is a repeat; however, the BYO-credentials requirement is genuine context an agent needs before calling. No mention of auth-failure behavior, rate limits, or what happens for unknown product ids, which is the gap for an openWorld tool.

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

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

Two sentences, front-loaded with the action and resource, then the return field list, then prerequisites. Every clause carries information; no filler.

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

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

No output schema exists, so the description must carry the return shape—and it does by enumerating the price categories and averaging windows. Combined with the credential note, an agent has enough to call correctly; only error/edge behavior is absent.

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

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

Only one parameter (idProduct) with 0% schema description coverage; the description says 'for a product id', which is the bare minimum needed, but adds no format, origin (Cardmarket catalogue id), or validation guidance. Baseline 3 for a single self-named parameter is barely met, not exceeded.

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

Does the description clearly state what the tool does and how it differs from similar tools?

Specific verb+resource ('Get the Cardmarket price guide') scoped to a product id, and the enumerated price fields (SELL, LOW, TREND, foil variants, averages) make it unambiguous what the tool returns. Naming Cardmarket distinguishes it from tcgplayer_price_guide and scryfall_card_prices.

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

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

States a prerequisite (own Cardmarket credentials) and that it is read-only, implying the use case, but never says when to pick this over tcgplayer_price_guide or scryfall_card_prices, nor when it is inapplicable (e.g., non-Cardmarket-listed products).

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

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

Annotations already declare readOnlyHint and openWorldHint, but the description adds genuinely non-derivable context: it requires user-supplied credentials and names the four exact env vars, which is critical for an agent to know before calling. It does not mention rate limits, pagination, or result ordering, and 'Read-only' merely repeats the annotation.

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

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

Two short sentences with the search scope front-loaded and the credential requirement immediately after; the env var enumeration is verbose but operationally necessary. No filler sentences, though the trailing 'Read-only' is redundant with annotations.

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

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

For a 5-parameter search tool with no output schema and sparse schema descriptions, the description covers auth and the game default but omits what 'exact' toggles, how maxResults behaves, and what the response looks like. An agent could call it, but with avoidable uncertainty.

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

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

Schema description coverage is only 20% (only idLanguage is documented), so the description must carry weight; it does explain that idGame=1 means Magic, adding real meaning the schema lacks. However, 'exact' and 'maxResults' remain unexplained in both schema and description, leaving half the semantics opaque.

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

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Search Cardmarket products by name') and pins the default game ('Magic by default, idGame=1'), which makes it clearly distinct from cardmarket_price_guide, cardmarket_seller_stock and cardmarket_compare_sellers. It does not explicitly contrast with tcgplayer_product_search or scryfall_search_cards, so it stops short of full sibling differentiation.

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

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

The scope (product name search, Magic default) implies when to use it, but there is no explicit statement of when to prefer it over scryfall_search_cards or tcgplayer_product_search, nor any exclusions. Usage must be inferred from the marketplace name.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered; the description still adds real value by stating the data is 'public stock' (scope limit) and that a BYO Cardmarket credential is required (auth prerequisite). It does not mention pagination behavior or result caps, which keeps it short of 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.

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

A single front-loaded sentence that leads with the resource and scope, then adds filters, purpose, and the credential prerequisite with no filler. It is efficiently sized for a four-parameter read tool.

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

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

No output schema exists, and the description does not say what a result record looks like or that results are capped/paginated, even though maxResults (max 200) and start imply paging. Combined with the phantom 'name search' filter and undocumented parameters, the definition leaves real gaps for an agent to fill by guessing.

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

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

Schema description coverage is only 25%, so the description must compensate, and it only partly does: it clarifies that 'user' accepts a username or id and that game filtering exists. Worse, it advertises a 'name search' filter that has no corresponding parameter in the schema, while the two pagination-related parameters (start, maxResults with a 1-200 range) go entirely unexplained.

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

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: a read-only view of a Cardmarket seller's public stock, keyed by username or user id, with the intent 'compare their prices against market'. It is distinguishable from cardmarket_product_search and cardmarket_price_guide, though it never names the closest sibling (cardmarket_compare_sellers) to sharpen the boundary.

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

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

The phrase 'so you can compare their prices against market' implies the use case, and 'Requires your own Cardmarket credentials' flags a prerequisite. But there are no explicit when-to-use/when-not rules and no routing to alternatives such as cardmarket_compare_sellers, leaving selection to inference.

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

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

The readOnlyHint is reinforced with explicit wording that this is SUGGESTION ONLY and that the server never creates, edits, or deletes listings. It also discloses that cardmarket mode fetches live data using the caller's credentials, adding useful context beyond the annotations, though it does not describe rate limits or return behavior.

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

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

The description is front-loaded with purpose and safety, then moves into input modes and strategy options. It is compact and largely waste-free, though the parenthetical credential note is slightly dense.

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

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

For a 12-parameter tool with no output schema and low schema description coverage, the description should explain more about required reference fields for manual mode, the tcgplayer path, and the shape of the returned suggestion. It covers the central concept and safety behavior well but leaves meaningful gaps.

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

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

Schema description coverage is only 17%, and the description compensates for some key parameters: currentPrice, marketplace modes, idProduct, and the strategy enum including the competitive default. It omits important semantics for many other parameters, including tcgplayer mode, floorPrice, undercutPct, minCondition, foil, and competitorPrices, so coverage of the 12-parameter schema is only partial.

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

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'Suggests a new price for ONE of your listings.' It also immediately distinguishes this advice tool from mutation tools by saying the server never creates, edits, or deletes listings.

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

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

It clearly explains the two input modes: Cardmarket with idProduct and credentials, or manual mode with your own reference numbers. However, it does not explicitly position the tool against sibling price-guide or seller-comparison tools, so the when-to-use guidance is strong but not fully comparative.

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

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

Annotations already cover readOnly and open-world behavior, yet the description still adds real operational context: it is free, needs no credentials, reads Scryfall bulk-derived data, and is refreshed daily. It stops short of saying how staleness or missing cards are handled, but the annotation bar is already met.

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

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

Three compact clauses, front-loaded with the cost/credential signal an agent needs first, then capability, then data provenance. No filler sentences.

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

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

For a 3-parameter read-only tool with no output schema, the description names the returned price fields and the data freshness, which is most of what an agent needs. The remaining gap is the unexplained 'all_printings' toggle and no note on behavior when a fuzzy match fails or returns multiple cards.

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

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

Only 'set' has schema documentation (33% coverage); the description usefully clarifies that 'name' is a fuzzy match and enumerates which price fields come back. However, 'all_printings' is never explained, and the claim of returning 'all printings' prices sits awkwardly beside a parameter that defaults to false, leaving the agent to guess the actual default scope.

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

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Fuzzy-name card lookup returning all printings' prices') plus the currency fields returned, and names the data source (Scryfall bulk-derived, daily). It is clearly separable from the cardmarket/tcgplayer siblings by source and currency set, though it never explicitly contrasts itself with those price-guide tools.

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

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

'FREE tier' and 'No credentials' imply when to prefer this over credentialed price sources, and 'fuzzy-name lookup' hints at the input style. But there is no explicit when-to-use/when-not guidance versus tcgplayer_price_guide or cardmarket_price_guide, which are the obvious alternatives for price data.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds real value beyond that: no credentials needed, free tier, and the exact return payload (ids, set info, USD/EUR/TIX prices, Cardmarket/TCGplayer product ids). It omits rate limits and pagination, keeping it below 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.

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

Three tight sentences with no waste and the key differentiator ('FREE tier') front-loaded. The example is well placed, though 'FREE tier. Requires no credentials' is mildly redundant with the later sentence.

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

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

With only 3 params, no output schema, and light annotations, the description does the heavy lifting by enumerating return fields and credential requirements. It's not fully complete because the meaning of 'unique' and 'limit' behavior (caps, defaults) is never addressed.

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

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

Schema coverage is only 33%: only 'query' is documented, and the description compensates usefully with a Scryfall syntax example ('o:flying t:dragon'). However, 'limit' and 'unique' are left unexplained in both schema and description, so the gap is only partly filled.

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

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Search Magic cards') and specifies the mechanism ('Scryfall syntax') with an example. It distinguishes itself from the paid-API siblings by noting the returned product ids are 'for use with the paid-API tools', though it doesn't name any sibling explicitly.

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

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

Clear context is given: this is the 'FREE tier' tool that 'requires no credentials', implicitly positioning it ahead of the paid cardmarket/tcgplayer tools for discovery. It doesn't give explicit when-not or name a specific alternative to use instead, so it stops short of full routing guidance.

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

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

Annotations already cover read-only and open-world behavior, so the description's 'Read-only' adds nothing. What does add value is the BYO-key authentication requirement and the disclosure of what is returned (five price tiers broken out by subtype), which the agent cannot learn from annotations alone.

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

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

Three terse clauses, front-loaded with the return payload, then the id constraint, then the prerequisite. Every fragment carries information; nothing is padding.

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

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

For a one-parameter read tool with no output schema, the description tells the agent what comes back and what credentials are needed. The remaining gap is discoverability of product ids and the absence of a response shape, but neither blocks correct invocation.

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

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

Schema coverage is 0%, so the description must carry the parameter meaning — and it does partially, clarifying that productIds are TCGplayer product ids and that the cap is 50 (the schema states maxItems but not what an id is or where to get one). It omits any pointer to a lookup tool, leaving a real gap for a zero-coverage schema.

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

Does the description clearly state what the tool does and how it differs from similar tools?

States concretely what the tool returns (market/low/mid/high/direct-low prices per Normal/Foil subtype) for a specific resource (TCGplayer product ids). The 'TCGplayer' qualifier implicitly separates it from cardmarket_price_guide and scryfall_card_prices, but it never names those alternatives explicitly.

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

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

Usage is implied by the marketplace name and the 'Requires your own TCGplayer keys' prerequisite, which is a useful gating condition. However, it never says when to prefer this over cardmarket_price_guide or scryfall_card_prices, nor how to obtain product ids (presumably via tcgplayer_product_search).

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

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

Annotations already declare readOnlyHint and openWorldHint, but the description adds genuinely new context: it requires caller-supplied credentials via TCGPLAYER_CLIENT_ID/TCGPLAYER_CLIENT_SECRET and warns that key issuance is currently restricted, which materially changes whether an agent should attempt the call. It does not cover rate limits or result shape, keeping it below 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.

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

Four short sentences, front-loaded with purpose, then constraints. No filler, though the "Read-only" clause duplicates readOnlyHint and the key-availability warning could be folded into the credentials sentence.

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

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

For a 3-parameter search with no output schema, the description covers auth and one enum-like value but leaves the success shape unknown — it never hints that results are product entries with IDs that downstream price-guide tools consume. Adequate to attempt the call, not enough to plan a multi-tool workflow.

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

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

Schema coverage is 0%, so the description carries the full documentation burden, yet it only annotates one parameter (categoryId 1 = Magic). It never clarifies whether productName is exact-match or substring, what limit actually caps, or what categoryId values exist beyond Magic.

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

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ("Search TCGplayer catalog products by name") and scopes it to a named marketplace, which inherently distinguishes it from the scryfall_* and cardmarket_* siblings. An agent can tell which catalog it targets without opening the schema.

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

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

Gives prerequisites (own API keys in env) and an availability caveat, plus one concrete usage hint (Magic is categoryId 1). However, it never says when to prefer this over scryfall_search_cards or cardmarket_product_search, nor what happens when a search is too broad or returns nothing.

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