cz-mtg-compare-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.6.0
Disambiguation5/5
Each tool targets a distinct operation: listing shops, searching cards, optimizing decklists, managing cart/watchlist, and account capabilities. No two tools have overlapping purposes; even similar actions like add_to_cart and view_cart are clearly separated by verb.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern with underscores (e.g., list_shops, search_card, add_to_cart). No mixing of camelCase or other conventions.
Tool Count5/5
10 tools is well within the ideal 3-15 range for a focused server. Each tool earns its place for a comprehensive MTG shopping experience.
Completeness4/5
The toolset covers the core workflow: search, optimize, cart management, login, and watchlist. Minor gaps exist, such as no ability to remove a single item from cart (only clear all) or update cart quantities, but these are not critical.
Average 4.3/5 across 10 of 10 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 5 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden. It indicates a read operation but does not disclose any potential side effects, authentication requirements, or rate limits. The meaning of 'last-call status' is not explained, leaving some ambiguity about the data returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It efficiently conveys the tool's purpose.
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?
Given zero parameters and the existence of an output schema (which likely describes the return structure), the description is adequate. It could be improved by clarifying 'last-call status', but it is complete enough for a simple list tool.
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?
There are no parameters (schema coverage 100%), so the description does not need to add parameter details. The baseline is 4, and the description is sufficient as it does not repeat schema information.
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 clearly states the verb 'List', the resource 'configured shops', and includes 'with their last-call status' to specify the information returned. This distinguishes it from sibling tools which focus on cart operations, card searching, and account management.
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?
The description does not explicitly state when to use this tool versus alternatives. While the sibling tools have distinct purposes (e.g., add_to_cart, search_card), no direct guidance is provided for when this tool is preferred or not.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the tool raises AccountFeatureNotSupported if the shop lacks a watchlist, but does not cover other behavioral aspects like authentication requirements, idempotency, or side effects.
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 three sentences, front-loaded with the main purpose. Each sentence adds distinct information. It is concise without being terse.
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?
Given the tool's simplicity (2 params, no annotations, but presence of output schema), the description covers the essential aspects: action, parameter semantics, preconditions, and error handling. No critical gaps are apparent.
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 0%, so description must add value. It clarifies that shop_ref is the same identifier used by add_to_cart, which is helpful. However, it does not explain the shop parameter beyond what the enum provides.
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 clearly states the action ('Add an offer to the shop's wishlist') and resource. It distinguishes from sibling tools like add_to_cart by specifying the target (watchlist vs cart).
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?
The description tells when to use the tool (when shop supports watchlist) and references shop_account_capabilities as a prerequisite. It also explains the shop_ref parameter's relationship to add_to_cart. However, it does not explicitly state when not to use or list alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses default sorting (price_czk ascending), exclusion of non-playable cards, and shop filtering logic. No annotations exist, so description carries full burden; it is thorough but omits rate limits or auth requirements.
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?
Front-loaded with purpose and output details. Reasonably concise, though the shop logic explanation could be more terse. No wasted sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 6 parameters and no schema descriptions, the description covers most critical aspects but omits 'edition' and 'in_stock_only' semantics. Output schema exists but isn't shown; still, the return field list is provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must explain all parameters. It explains shops, exclude_shops, and include_non_playable, but does not mention the 'edition' parameter or the 'in_stock_only' default behavior. This leaves gaps.
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 clearly states the tool searches Magic cards across Czech shops and returns sorted offers. It distinguishes from sibling tools like lookup_card (card details) and list_shops (shop listing).
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?
Provides clear context for shop filtering (allow/deny lists) and when to include non-playable cards. Does not explicitly state when not to use this tool versus alternatives, but the sibling context helps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, the description fully discloses the destructive nature (requires confirmation) and the return format (\`{"removed_items": <int>}\`). This adds behavioral context beyond the schema. It could be improved by specifying that the entire cart is cleared, not partial, but the current detail is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences and a return type snippet. Every part adds value (purpose, destructive warning, return format). No filler or redundancy.
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 simple tool with one parameter and a clear return, the description is nearly complete. It covers purpose, destructive behavior, and return format. The only gap is the lack of parameter explanation, but the output schema is present and the sibling tools (e.g., list_shops) might provide context. Overall, it adequately supports an agent in selecting and invoking the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter 'shop' with an enum but no description. The tool description does not explain what 'shop' represents or list the valid values. With 0% schema description coverage, the description should compensate but fails to add meaningful parameter semantics. The agent must infer from the tool name and siblings like list_shops.
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 clearly states the verb ('Remove'), resource ('every item from the shop's online cart'), and scope ('for the authenticated user'). This distinguishes it from siblings like view_cart (viewing) and add_to_cart (adding). The purpose is specific and unambiguous.
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?
The description explicitly mentions the tool is destructive and advises confirming with the user before calling, which provides clear usage guidance. However, it does not specify when to use alternatives like add_to_cart (for adding items) or view_cart (for inspection), though the destructive hint strongly implies caution.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses automatic login behavior. No annotations provided, so description carries full burden; is reasonably transparent for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff. Perfectly sized for the tool's simplicity.
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?
Covers purpose and key behavior (auto-login). With output schema present, return values need no description. Minor gap: no mention of empty cart handling.
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 has enum for 'shop' but no description; parameter meaning is clear from context. No extra detail added beyond schema.
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?
Clearly states 'Return the current contents of the shop's online cart', using a specific verb and resource. Distinguishes from siblings like add_to_cart and clear_cart.
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?
Implicitly indicates when to use (viewing cart) and notes automatic login, but lacks explicit exclusions or alternatives for viewing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description discloses automatic login and re-login behavior and the raw return format. It does not fully cover error handling or potential side effects like duplicate handling, but the disclosed behaviors are helpful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at 5 sentences, front-loaded with the core purpose, and each sentence adds value without redundancy.
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?
Given the presence of an output schema, the description adequately covers return value, parameter usage, and authentication. It could be improved by mentioning edge cases like failed additions, but overall it's sufficient.
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?
With 0% schema description coverage, the description compensates well by detailing shop_ref with examples and warnings. However, it lacks explanation for the 'shop' and 'count' parameters beyond what the schema provides.
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 clearly states the tool adds a count of a specific offer to the shop's online cart, which is a precise verb+resource pair. It distinguishes itself from siblings like add_to_watchlist by focusing on cart operations.
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?
The description explicitly instructs to call search_card first if the shop_ref is missing, providing clear guidance on when to use this tool. However, it does not explicitly state when not to use it (e.g., vs. add_to_watchlist).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses return fields, null return on no match, and the fuzzy vs. exact search behavior. Could mention rate limits or Scryfall API details, but for a read-only lookup it is adequately transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus a list of return fields, all front-loaded. Every sentence adds value: purpose, use cases, and parameter clarification. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 params, output schema exists), the description covers all essential aspects: purpose, return values, behavior on no match, and parameter options. The output schema covers return format, so no additional explanation needed.
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 0%, so description must compensate. It explains the 'exact' parameter (set to true for exact match, default fuzzy) and the 'name' parameter implicitly as card name. Adds meaning beyond schema names, though 'name' could be more explicitly described.
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?
Description starts with 'Resolve a Magic: The Gathering card name via Scryfall,' clearly stating the verb-resource pair. It distinguishes from sibling 'search_card' by focusing on resolving a single name with fuzzy/exact matching, and lists key return fields (canonical name, set, oracle text, mana cost, image URL, Scryfall URI).
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?
Explicitly states usefulness for 'disambiguating reprints, validating spelling, or fetching multilingual names,' providing clear context for when to use. Does not explicitly mention when not to use or compare to siblings, but the context is sufficient for the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully bears the burden of behavior disclosure. It details parallel requests, strategy logic, limits (100 cards/unique cards), default exclusions, shop filtering, and response shape, leaving no major behavioral gaps.
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 description is well-organized in sections but overly verbose, running multiple paragraphs. While thorough, it could be more concise without losing essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (two strategies, multiple parameters, output schema), the description is highly complete. It covers response fields, conditional behavior, user presentation guidance, and edge cases like missing cards, exceeding the schema alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It does so thoroughly for all 6 parameters, explaining strategy options, shop filtering, include_non_playable, and in_stock_only, far beyond just listing them.
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 clearly specifies the tool's purpose: 'Resolve a Magic decklist against all shops in parallel and return a shopping_plan.' It differentiates from siblings like search_card (single card) and add_to_cart (cart operations) by focusing on batch optimization.
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?
The description explains when to use the tool and details two strategies with trade-offs, constraints, and override mechanisms. However, it does not explicitly state alternatives for single-card lookups or when not to use it, though the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description fully discloses session reuse, credential handling (including 1Password), error cases, and return format.
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?
Multi-sentence but well-structured and front-loaded. Each sentence adds value. Slightly longer than necessary but not excessive.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete given single param and implied output schema. Covers inputs, behavior, session lifecycle, and error messages.
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?
Only one parameter with enum; description adds value by explaining credential naming convention (CZ_MTG_<SHOP>_USER / _PASS), not in schema. Schema coverage 0%, description compensates well.
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?
Clearly states authentication against a shop using credentials. Distinguishes from siblings like add_to_cart and view_cart.
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?
Explains when to use (before add_to_cart/view_cart) and reuses sessions. No explicit when-not-to-use, but context from sibling tools implies it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full behavioral burden. It explains that credential check is a presence check of env vars and does NOT resolve 1Password references, which is a critical behavioral detail. Also notes it returns one entry per enabled shop.
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?
Description is well-structured with bullet points and code formatting. It is somewhat lengthy but every sentence adds value. Could be slightly more concise, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and no output schema (but description provides output structure), the description is fully complete. It covers purpose, behavior, usage guidance, and output details, leaving no gaps for an agent to misinterpret.
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?
No parameters in schema, so baseline is 4. Description adds meaning by detailing output fields and their significance, compensating for the lack of parameters.
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 clearly states it returns 'Per-shop account-feature support and credential status.' It lists specific output fields and distinguishes from sibling tools like shop_login by focusing on capability checking rather than performing actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this to tell the user which shops they can actually log into and which account actions are available before attempting them.' This provides clear when-to-use guidance and implies alternatives (e.g., shop_login for actual login).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

czech-mtg-price-comparator-mcp MCP server

Copy to your README.md:

[![czech-mtg-price-comparator-mcp MCP server](https://glama.ai/mcp/servers/xvyslo05/czech-mtg-price-comparator-mcp/badges/card.svg)](https://glama.ai/mcp/servers/xvyslo05/czech-mtg-price-comparator-mcp)

Score Badge

Copy to your README.md:

[![czech-mtg-price-comparator-mcp MCP server](https://glama.ai/mcp/servers/xvyslo05/czech-mtg-price-comparator-mcp/badges/score.svg)](https://glama.ai/mcp/servers/xvyslo05/czech-mtg-price-comparator-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/xvyslo05/czech-mtg-price-comparator-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server