lorcana-mcp

Server Quality Checklist

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

Latest release: v2.3.0
Disambiguation5/5
Each tool targets a distinct task: search returns card objects, count returns totals, aggregate returns grouped counts, top_traits returns trait frequencies, resolve_card handles fuzzy name matching, and the deck tools each handle import, export, validation, or stats. No two tools overlap in purpose, and the descriptions make the boundaries clear.
Naming Consistency3/5
Most tools follow a verb_noun pattern (search_cards, count_cards, aggregate_cards, resolve_card, export_deck, import_deck, validate_deck), but top_traits, server_status, and deck_stats use noun phrases. The mixed convention is still readable but not uniformly predictable.
Tool Count5/5
With 10 tools, the set is well-scoped for a Lorcana card and deck assistant. It covers both card querying (search, count, aggregate, resolve) and deck management (import, export, validate, stats) without unnecessary bloat.
Completeness5/5
The tool surface provides comprehensive coverage for the domain: card discovery, count/aggregation, fuzzy name resolution, deck import/export, format validation, and detailed deck statistics. Common workflows like 'search for a card -> build a deck -> validate -> analyze stats' are fully supported with no obvious dead ends.
Average 4.1/5 across 10 of 10 tools scored. Lowest: 2/5.
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
- Last stable release on August 3, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It only states 'return most common traits' with no mention of side effects, data source, ordering, or limitations. Completely opaque.
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?
Extremely concise (3 words), but at the expense of clarity. It could be expanded slightly without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple but the description lacks context about what 'traits' are, expected input/output, and how it relates to sibling tools. The output schema exists but is not described.
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 only parameter 'limit' has a default of 10 but the description does not explain its meaning (e.g., maximum number of traits). Schema coverage is 0%, so description should compensate but fails.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Return most common traits' identifies a verb and resource, but 'traits' is vague and not differentiated from sibling tools like 'aggregate_cards'. It lacks specificity about what traits are (e.g., card traits).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description gives no context or exclusions, leaving the agent to guess.
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?
With no annotations, the description carries the full burden. It discloses filter behavior (e.g., case-insensitive substring for set_name, matches against structured ability list for keyword) and stat ranges. Some behavioral details like AND/OR logic for multiple filters are missing but overall it is transparent.
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 the purpose and usage examples. It is organized by parameter groups but could be more concise, especially the list of keywords. Most sentences add value.
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 complexity of 20 parameters and no annotations, the description covers many filter options and their semantics. The presence of an output schema reduces the need to explain return values. However, it lacks explanation of how multiple filters combine (e.g., AND logic) and does not mention edge cases like no matches.
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 description coverage is 0%, so the description must compensate. It explains many parameters (keyword, body_text, lore, card_type, set_code, set_name, color, stat ranges) but fails to explain several others like name, trait, rarity, inkwell, and the single cost parameter. With 20 parameters, coverage is insufficient.
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 states 'Count cards matching the given filters' and provides examples like 'how many ruby cards are there?' which clearly conveys the purpose. It does not explicitly differentiate from sibling tools like search_cards, but the verb 'count' distinguishes it effectively.
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 gives explicit examples of questions to use the tool for ('how many ruby cards are there?') and explains when to use keyword vs body_text. However, it does not mention when not to use this tool or suggest alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description lacks behavioral details such as read-only nature, rate limits, or output format, leaving agent uninformed.
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, front-loaded purpose, includes examples, no wasted words.
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?
Functional for basic use, but missing description of output structure despite available output schema; behavioral gaps reduce completeness.
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 coverage, description adds examples and lists valid field values, compensating for schema gap.
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 it returns card counts grouped by a field, lists valid fields, and gives examples, distinguishing it from siblings like count_cards.
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 valid field options and examples for use, but does not explicitly state when to avoid or name alternatives.
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?
Without annotations, the description carries the burden. It states 'Show' implying a read-only operation, but does not elaborate on metadata content or side effects. Adequate given no parameters.
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?
A single, clear sentence with no unnecessary words. Every part serves the 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 the simplicity (no parameters, trivial purpose) and the presence of an output schema (presumably detailing return format), the description sufficiently covers what the tool does.
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 exist (0 params, 100% schema coverage), so the description need not add parameter details. Baseline score of 4 is appropriate.
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 specifies a clear verb ('Show') and resource ('startup metadata for this server instance'). It distinguishes the tool from siblings, which focus on cards and decks.
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?
No explicit guidance on when or when not to use this tool, but the purpose is straightforward (server status check) and alternative tools are unrelated, so usage can be inferred.
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 carries full burden and succeeds: it discloses dual-ink counting behavior (sum may exceed total_cards), the handling of unresolved names (listed separately, excluded from per-card stats, still counted in total_cards), and the inclusion of per-card keyword tags.
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 a dense paragraph, but every clause adds specific information about a stat or edge case. It is longer than ideal, but the length is justified by the variety of stats. Slight chunking into bullets would improve scannability.
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?
Output schema exists to cover return values, and the description thoroughly covers behavioral edge cases and stat semantics. The only minor gap is the implicit, not fully explicit, mapping from the deck parameter to the described entry format; otherwise it is complete for a tool of this complexity.
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?
The `deck` parameter has zero schema coverage, but the description partially compensates by indicating each entry is `{name, count}` where name is the card's full_name and explaining how unresolved names are handled. It could be more explicit about the deck input format (e.g., that deck is the array of these entries), but enough meaning is added beyond the 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?
The description opens with an explicit verb and object ('Compute summary stats for a Lorcana deck') and enumerates all stat categories (ink curve, color split, inkable counts, type breakdown, keyword/subtype counts, card_keywords). This makes it clearly distinguishable from sibling search/count/aggregate tools.
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?
It states a concrete benefit over an alternative ('answerable without a follow-up search_cards call'), which implies when to use this tool instead of searching. It does not explicitly enumerate when not to use it, but the scope (deck-level summarization) is clear.
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?
With no annotations, the description carries full burden. It states that the tool returns full card data (stats, abilities, cost, etc.) for each candidate, requiring no follow-up. It gives an example resolution. However, it does not explicitly state that the tool is read-only or that it performs no side effects. The behavioral disclosure is good but could be slightly more explicit.
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 and includes structured bullet points for usage scenarios. Every sentence adds value, though it is slightly verbose. The example is helpful. Overall well-structured and efficient, but could be trimmed slightly without losing content.
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 complexity (fuzzy name resolution), schema coverage 0%, and existence of an output schema, the description provides adequate context. It explains when to use it versus search_cards and what it returns. However, it lacks detail on the matching algorithm or confidence levels. The output schema covers return values, so description is mostly sufficient.
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 compensate. It explains the 'query' parameter implicitly through examples (e.g., 'Maui Half Shark') but does not describe its format or constraints. The 'limit' parameter is not mentioned at all, despite having a default of 5. The description adds some meaning for query but insufficiently for both 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 the tool resolves informal, partial, or misspelled card names to closest matching cards, returning full card data. It explicitly distinguishes from sibling tool search_cards, noting that when a specific card is named, resolve_card should be used instead to avoid failed searches. The verb 'resolve' and resource 'card name' are 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use scenarios: 'Tell me about X' -> use resolve_card directly; 'Find cards that synergize' -> resolve_card then search_cards; 'Build a deck' -> resolve_card then search_cards. It also gives a strong when-not-to-use: 'Never call search_cards first when the user has named a specific card.' This is comprehensive and prevents misuse.
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 the full burden. It details the validation rules, violation types (deck_size, max_copies, ink_limit, unknown_card), and return structure. It does not mention side effects (assumed read-only) or error handling beyond unknown_card, but the behavioral disclosure is substantial.
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 well-structured, starting with purpose, then rules, input format, return format, violation types, and usage note. It is slightly long but every sentence adds value. Could be slightly more concise.
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 complexity of deck validation (multiple rules) and the existence of an output schema, the description is complete. It covers all rules, violation types, input format, return structure, and integration with import_deck. The output schema likely details return fields, so the description need not repeat them.
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?
The input schema has only one parameter 'deck' with minimal type info (array of objects, additionalProperties true). The description adds critical meaning: each entry must be {name: str, count: int} with name as card.full_name, provides an example, and explains how to build from import_deck output. This fully compensates for the 0% schema coverage.
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 validates a Lorcana deck against format rules, specifying the verb 'validate' and resource 'deck'. It distinguishes from sibling tools like import_deck (which parses a deck) and deck_stats (likely summary).
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 provides clear context for use: validating a deck after importing via import_deck. It explains the input format and how to build it from import_deck output. However, it does not explicitly mention when not to use this tool or alternatives like search_cards for resolving unknown cards.
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?
With no annotations, the description carries full burden. It accurately describes the output format and input requirements. It lacks details on error handling or authorization but is adequate for a read-only export tool.
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, well-structured sentence that front-loads the core purpose and includes all necessary details without redundancy.
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 single parameter and clear return type (plain text), the description provides sufficient context. It explains the input structure and output format, making the tool complete for its intended use.
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?
The schema is minimal with additionalProperties: true. The description adds critical meaning by explaining that each array item must have 'name' and 'count' fields, with name being the full_name from search_cards. This compensates for the 0% schema coverage.
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's purpose: rendering a Lorcana deck into a Dreamborn/Pixelborn-compatible text format. It specifies the output format, naming convention, and use cases, distinguishing it from siblings like import_deck or validate_deck.
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 implicitly indicates when to use the tool (for exporting decks to external platforms) and provides context about compatible tools. However, it does not explicitly state when not to use it or compare with alternatives.
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 the description fully discloses behavior: exact match first, fuzzy fallback, returned structure with parsed and unresolved, and silent skipping of blank lines, comments, totals, and section headers. No side effects or hidden constraints are omitted.
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?
Three sentences, front-loaded with purpose, then detail on matching behavior and output shape. Every sentence adds unique value without redundancy.
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 output schema exists, the description covers input format, processing rules, and output structure comprehensively. It leaves no gaps for an agent to use the tool effectively.
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?
The single 'text' parameter has 0% schema coverage, but the description enriches it by specifying the expected format (`<count> <full_name>` per line) and what content is ignored. This provides essential guidance beyond the 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?
The description clearly states the tool parses a Dreamborn/Pixelborn-style deck list into resolved card objects, specifying input format and output structure. It distinguishes itself from siblings like export_deck and resolve_card by focusing on bulk parsing with fuzzy matching.
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 advise when to use this tool versus alternatives like resolve_card or search_cards for single cards, nor does it mention prerequisites or forbidden inputs. Usage context is implied but not directly communicated.
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 the full burden. It discloses that the tool returns card objects (not counts), explains the TOON encoding option for token savings, and implies read-only behavior through its search nature. However, it does not explicitly state that the operation is idempotent or free of side effects, which is acceptable given the context. The description is transparent enough for a search 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?
The description is well-structured, starting with the core purpose and then systematically covering each parameter. It uses clear language and examples. While it is lengthy (necessary due to 25 parameters), it remains focused and every sentence contributes meaning. A slight deduction for verbosity at times, but overall efficiently organized.
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 complexity of 25 parameters and the presence of an output schema, the description covers all essential aspects: parameter usage, pagination, sorting, output format options, and alternative tools. It provides complete guidance for an agent to correctly invoke the tool, including edge cases like set_name vs set_code. The description is thorough and leaves no critical gaps.
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?
With schema description coverage at 0%, the description fully compensates by explaining the purpose and usage of most parameters in detail. It lists valid color values, explains keyword vs body_text differences, provides sort_by options, and clarifies set_name preference over set_code. Only a few parameters like 'trait' and 'name' are not explicitly described, but the coverage is extensive and adds significant value beyond the 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?
The description clearly states the tool's purpose: 'Search Lorcana cards with optional filters.' It explicitly mentions it returns card objects (not counts), distinguishing it from count_cards. The verb 'search' combined with 'Lorcana cards' and the mention of filters makes the purpose 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides extensive guidance on when to use this tool versus alternatives, such as 'Use count_cards instead if you only need a total count.' It explains when to use specific parameters for different query types (e.g., keyword vs body_text, set_name vs set_code) and how to paginate with offset. This gives clear context for usage.
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

Copy to your README.md:

[![lorcana-mcp MCP server](https://glama.ai/mcp/servers/danielenricocahall/lorcana-mcp/badges/card.svg)](https://glama.ai/mcp/servers/danielenricocahall/lorcana-mcp)

Score Badge

Copy to your README.md:

[![lorcana-mcp MCP server](https://glama.ai/mcp/servers/danielenricocahall/lorcana-mcp/badges/score.svg)](https://glama.ai/mcp/servers/danielenricocahall/lorcana-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/danielenricocahall/lorcana-mcp'

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