lorcana-oracle
Server Quality Checklist
Latest release: v1.0.0
- Disambiguation5/5
Each tool has a clear, distinct purpose. Even though analyze_ink_curve and analyze_lore both accept deck lists, they analyze different dimensions (ink curve vs. lore). browse_franchise and browse_sets browse by different facets. No substantial overlap exists.
Naming Consistency4/5Most tools use a verb_noun pattern (analyze_, browse_, find_, search_). The exception is 'character_versions', which is a noun phrase. This minor inconsistency lowers the score slightly.
Tool Count5/5With 7 tools, the server is well-scoped for a card game reference. Each tool serves a meaningful purpose without redundancy, and the number feels balanced for the domain.
Completeness4/5The tool set covers core needs: card search, browsing by set/franchise, deck analysis (ink curve and lore), character versions, and song synergies. Minor gaps like collection tracking or meta analysis exist but are outside the stated purpose.
Average 4/5 across 7 of 7 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- Last stable release on
- 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.
This repository includes a glama.json configuration file.
This server has been verified by its author.
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?
No annotations are provided, so the description must fully convey behavioral traits. It mentions analyzing and returning curve analysis, but does not disclose whether the tool modifies data, handles invalid input, or requires authentication. This is insufficient for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, each serving a distinct purpose: defining the analysis and instructing usage. No redundant or irrelevant information, and the core action is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one simple parameter with full schema coverage and no output schema or annotations. The description adequately explains the purpose and usage, but does not specify the format of the output (e.g., table, chart) or any error handling, leaving some gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters with a clear description ('Deck list text, one card per line...'), so the baseline is 3. The description adds 'Paste a deck list to get curve analysis', which reinforces usage but does not provide additional semantic information beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it analyzes a Disney Lorcana deck list for specific metrics (ink cost distribution, inkable ratio, color balance), distinguishing it from sibling tools like analyze_lore or search_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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description tells the user to paste a deck list to get analysis, providing clear context. However, it lacks guidance on when not to use this tool or alternatives, and does not specify prerequisites for valid input beyond the schema.
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 must cover behavioral traits. It mentions pagination via 'Returns paginated results', but does not disclose read-only nature, error handling, or behavior when filters yield no results. The pagination hint is helpful but limited.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the core functionality. It front-loads the verb and lists filters compactly. Minor improvement could be separating the pagination mention for clarity, but overall concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description covers essential aspects: input types (name, rules text, filters) and pagination. It does not specify optionality of parameters or default limit, but for a search tool with extensive schema, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions. The description adds little beyond summarizing filter options; it does not clarify parameter interactions (e.g., how query works with filters) or provide examples. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: searching Disney Lorcana cards by name, rules text, or multiple filters. It distinguishes itself from sibling analysis tools like analyze_ink_curve and browse_sets, which have different focuses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for finding cards via various criteria, but lacks explicit guidance on when to use this tool versus alternatives, such as analyze_ink_curve for ink cost distribution or find_song_synergies for synergies. No when-not-to-use or alternative references are provided.
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 must carry full weight. It explains the analysis behavior (showing lore potential, ranking, filtering) but does not disclose read-only nature, rate limits, or side effects. Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences efficiently cover purpose, modes, and filtering. No redundant or extraneous text; front-loaded with the main function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description explains output in each mode (total lore potential, ranking, top generators). For a tool with 5 parameters, this is sufficient but could mention pagination or result format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage, so baseline is 3. The description mentions optional filters but does not add any meaning beyond what the schema already provides for parameters like ink, cost_min, cost_max, limit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool analyzes lore generation in deck lists and finds top lore-generating cards, with two distinct modes (deck and query). This is specific and differentiates from siblings like analyze_ink_curve or browse_franchise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use each mode (deck vs query), providing clear context. However, it does not explicitly state when not to use this tool or mention alternatives, leaving some ambiguity.
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 provided, so the description carries the burden. It states the tool shows versions but does not discuss output format, error handling, or potential side effects. Adequate for a simple query 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first explains function, second provides usage context. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given 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 no output schema, the description adequately conveys purpose and usage. Could mention output format but not essential.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
100% schema coverage with a clear parameter description. The description adds minimal extra meaning beyond the schema, just a usage note. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('show all printings/versions') and resource ('Disney Lorcana character across sets'), distinguishing it from sibling tools like search_cards or browse_sets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case ('useful for comparing different versions'), but does not explicitly state when not to use it or mention 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?
No annotations are provided, so the description carries full behavioral burden. It explains input-dependent behavior (Song vs Character) and the no-input case. However, it does not disclose what 'singer counts' means or any limitations (e.g., exact match vs fuzzy search). Adequate but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, no wasted words. The description is front-loaded with the purpose, then enumerates scenarios efficiently. Ideal length for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately covers core functionality and parameter usage. It could mention output format (e.g., list of cards) but the phrase 'browse all songs with singer counts' implies a tabular result. Slightly incomplete but sufficient for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters documented. The description adds value by clarifying that card_name can be a Song or Character and that the tool determines direction automatically. The ink parameter's filtering role is clear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds Disney Lorcana song synergies and explains three specific use cases: given a Song, find characters that can sing it; given a Character, find songs they can sing; with no input, browse all songs with singer counts. This specificity differentiates it from sibling tools like analyze_ink_curve or search_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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use each scenario based on input type. It implies alternatives (other analysis tools) but does not explicitly state when not to use this tool. The use cases are clear and actionable.
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. The description implies a read-only operation (listing/drilling) but does not explicitly state behavioral traits such as read-only nature, authentication requirements, rate limits, or any side effects. For a tool with no annotations, more explicit behavioral context would be beneficial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences, front-loading the primary action. Every sentence provides necessary information without any fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, no output schema, no annotations), the description adequately covers what the tool does and how to use it. It does not need to explain return values, as the behavior is straightforward.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single parameter set_code. The description adds value by explaining the two usage scenarios (omit vs. provide the code) and the effect of providing it (see cards in that set). This goes beyond the schema's simple description of the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (list or drill) and resource (Disney Lorcana sets), and specifies the two distinct modes: listing all sets or showing a specific set's cards. It distinguishes itself from siblings like search_cards by focusing on sets rather than generic card search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage guidance: omit set_code for listing all sets, provide it to drill into a specific set. It implicitly guides when to use this tool over search_cards (which is for broader card search), but does not explicitly state when not to use it 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?
No annotations are provided, so the description must communicate all behavioral traits. It discloses the two operational modes and implies a read-only browsing action. It does not mention any destructive side effects or limits, which is acceptable given the nature of browsing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using two short sentences to convey the tool's full purpose and usage. It is front-loaded with the core action and efficiently covers both invocation patterns.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description sufficiently covers the tool's functionality for an agent. It clarifies the dual behavior and parameter usage, though it could briefly hint at the nature of 'statistics' or 'cards' output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema describes the franchise parameter briefly. The description adds meaningful context: omitting the parameter lists all franchises, while providing it shows cards and statistics. This enhances understanding beyond the schema's description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: browsing Disney Lorcana cards by franchise. It distinguishes two behaviors: listing all franchises with card counts when no name is given, and showing cards and statistics with a specific name. This differentiates it from sibling tools like analyze_ink_curve or browse_sets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to omit or provide the franchise parameter, covering both use cases. However, it does not mention when not to use this tool or point to alternatives like search_cards.
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:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/gregario/lorcana-oracle'
If you have feedback or need assistance with the MCP directory API, please join our Discord server