sbwsz

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes focused on MTG card data retrieval (get_card_by_set_and_number, get_set, get_set_cards, get_sets, search_cards), but 'hzls' (活字乱刷) is an outlier for image generation, which could cause confusion if an agent expects purely data-oriented tools. The data tools are well-differentiated by scope (e.g., single card vs. set vs. search).
Naming Consistency3/5
Five tools follow a consistent 'verb_noun' pattern (e.g., get_card_by_set_and_number, get_set, get_set_cards, get_sets, search_cards), but 'hzls' uses an acronym without a clear verb-noun structure, breaking the pattern. This mixed convention reduces overall consistency, though the majority are readable.
Tool Count5/5
With 6 tools, the count is well-scoped for an MTG card data server, covering core operations like retrieving sets, cards, and searching, plus a creative tool. Each tool earns its place without being overwhelming or too sparse for the domain.
Completeness4/5
For MTG card data retrieval, the surface is nearly complete with tools for getting sets, cards by various criteria, and searching with advanced querying. The 'hzls' tool adds a creative function, but there might be minor gaps like updating or deleting data (if applicable), though these are likely out of scope for a read-focused server.
Average 3/5 across 6 of 6 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 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 Apache 2.0.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description only states what the tool does ('获取单张卡牌' - get a single card) without any behavioral traits such as whether it's read-only, if it requires authentication, error handling (e.g., what happens if the card isn't found), rate limits, or response format. This is inadequate for a tool with no annotation coverage.
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, efficient sentence that directly states the tool's purpose without any fluff. It's appropriately sized and front-loaded, making it easy to parse quickly. Every word earns its place by conveying essential information.
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?
Given the tool's complexity (a lookup operation with 2 required parameters), lack of annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects, usage context, parameter details, or return values. For a tool with no structured support, the description should provide more comprehensive guidance to be effective.
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 0% description coverage, so parameters 'set' and 'collector_number' are undocumented in the schema. The description adds minimal semantic value by naming these parameters ('系列代码' - set code and '收集编号' - collector number) but doesn't explain what they represent (e.g., format examples like 'M21' for set or '001' for collector number), valid values, or constraints. This partially compensates but leaves significant gaps.
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 clearly states the tool's purpose: '通过系列代码和收集编号获取单张卡牌' (Get a single card by set code and collector number). It specifies the verb ('获取' - get) and resource ('单张卡牌' - single card), and distinguishes it from siblings like get_set_cards (which likely gets multiple cards) and search_cards (which likely searches broadly). However, it doesn't explicitly differentiate from get_set, which might also retrieve card-related data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when this tool is appropriate (e.g., for precise lookup by known identifiers) or when not to use it (e.g., for searching by name or browsing sets). With siblings like search_cards and get_set_cards available, the lack of usage context is a significant gap.
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?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions pagination and sorting capabilities, but doesn't address important aspects like whether this is a read-only operation, rate limits, authentication requirements, error conditions, or what the response format looks like. The description is insufficient for a tool with 5 parameters and no output schema.
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 appropriately concise with just one sentence that states the core purpose and mentions key features (pagination and sorting). It's front-loaded with the main functionality, though it could be more structured by separating purpose from features.
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?
For a tool with 5 parameters, 0% schema description coverage, no annotations, and no output schema, the description is inadequate. It doesn't explain parameter meanings, expected behaviors, response format, or error handling. The mention of pagination and sorting is insufficient given the complexity of 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?
With 0% schema description coverage and 5 parameters, the description fails to compensate. It mentions pagination and sorting generally but doesn't explain what 'set_code', 'page', 'page_size', 'order', or 'priority_chinese' mean or how they should be used. The schema provides only basic type information without semantic context.
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 clearly states the tool's purpose: '获取特定系列的所有卡牌' (get all cards from a specific set). It specifies the resource (cards) and scope (specific set), though it doesn't explicitly differentiate from siblings like 'get_card_by_set_and_number' 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions pagination and sorting support, but doesn't explain when to choose this over 'search_cards' or 'get_card_by_set_and_number', nor does it mention prerequisites or exclusions.
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?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the core function (stitching text into images using card images) but lacks critical details: what '魔法卡牌' (magic cards) refers to, whether this requires authentication, rate limits, file format of output, error conditions, or what happens with the boolean parameters. For a tool with 3 parameters and no annotation coverage, this is insufficient.
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 concise (one sentence in Chinese) and front-loaded with the core purpose. However, the parenthetical '活字乱刷（使用卡牌图像拼接句子）' adds some redundancy with the main clause. Overall, it's efficient but could be slightly more streamlined by integrating the parenthetical explanation.
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?
Given 3 parameters with 0% schema coverage, no annotations, and no output schema, the description is incomplete. It explains the basic transformation (text → card-image picture) but misses: parameter meanings for 2/3 parameters, output format, error handling, and how it relates to sibling tools. For a tool that presumably generates visual output, more context about the result is needed.
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 for undocumented parameters. It only mentions '输入的文本' (input text), which corresponds to 'target_sentence'. The two boolean parameters ('cut_full_image' and 'with_link') are completely unexplained in the description. With 3 parameters total and only 1 addressed, the description adds minimal semantic value beyond the bare schema.
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 clearly states the tool's purpose: '将输入的文本使用魔法卡牌图像拼接成图片' (use magic card images to stitch input text into a picture). It specifies the verb ('拼接' - stitch/assemble), resource ('卡牌图像' - card images), and output format ('图片' - picture). However, it doesn't explicitly differentiate from sibling tools like 'get_card_by_set_and_number' or 'search_cards', which appear to be query tools rather than image generation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, constraints, or comparison with sibling tools like 'get_sets' or 'search_cards'. The only implied usage is when text needs to be converted to card-based images, but no explicit when/when-not instructions are provided.
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 are provided, so the description carries the full burden of behavioral disclosure. It states this is a read operation ('获取' - get), but doesn't describe what '详细信息' (detailed information) includes, potential errors (e.g., invalid set_code), response format, or any rate limits. For a tool with no annotation coverage, this leaves significant gaps in understanding its behavior.
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, efficient sentence that directly states the tool's purpose without unnecessary words. It is appropriately sized and front-loaded, with no wasted information, making it easy to parse quickly.
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?
Given the tool's simplicity (one parameter, no annotations, no output schema), the description is incomplete. It doesn't explain what '详细信息' (detailed information) includes in the response, potential error cases, or how it differs from sibling tools. For a tool with no structured data to rely on, more context is needed to fully understand its use.
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 description adds minimal meaning beyond the input schema. It explains that 'set_code' is used to '获取单个系列的详细信息' (get detailed information of a single series), which clarifies the parameter's purpose. However, with 0% schema description coverage and only one parameter, this provides basic context but doesn't detail format constraints or examples. The baseline is 4 for zero parameters, but here there is one parameter with some added semantics.
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 clearly states the tool's purpose: '根据系列代码获取单个系列的详细信息' (Get detailed information of a single series based on series code). It specifies the verb ('获取' - get) and resource ('单个系列的详细信息' - detailed information of a single series). However, it doesn't explicitly differentiate from sibling tools like 'get_sets' (likely for multiple series) or 'get_set_cards' (likely for cards within a series), leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'get_sets' (for listing series) or 'get_set_cards' (for cards in a series), nor does it specify prerequisites or exclusions. Usage is implied only by the purpose statement, with no explicit context for selection.
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 are provided, so the description carries the full burden. It states the tool returns data sorted by release date in descending order, which is useful behavioral context. However, it lacks details on permissions, rate limits, pagination, or response format, which are critical for a data-fetching tool with no output schema.
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, efficient sentence in Chinese that states the action, resource, and sorting behavior without any wasted words. It is appropriately sized and front-loaded with the core purpose.
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?
Given the complexity (a data-fetching tool with no output schema and no annotations), the description is incomplete. It explains what data is returned and the sorting order but omits details on response structure, error handling, or limitations, which are essential for the 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter information, which is appropriate here. A baseline of 4 is applied as it compensates for the lack of parameters by focusing on the tool's purpose and behavior.
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 clearly states the verb ('返回' meaning 'return') and resource ('所有MTG卡牌系列的完整数据' meaning 'complete data of all MTG card sets'), making the purpose specific. However, it doesn't explicitly distinguish this tool from sibling tools like 'get_set' or 'get_set_cards', which appear to be related to MTG sets but likely serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'get_set' (which might fetch a single set) or 'get_set_cards' (which might fetch cards within a set), leaving the agent to infer usage based on tool names alone.
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 provided, the description carries full burden and does well by disclosing key behaviors: pagination support (page/page_size with defaults and limits), sorting capabilities (order parameter with syntax), and special features like unique deduplication and Chinese card priority. It doesn't mention rate limits, authentication needs, or error handling, but covers substantial operational details.
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 with clear sections (query syntax, pagination, sorting, other parameters) and uses bullet points effectively. Every sentence provides essential information, though it could be slightly more front-loaded with a summary before diving into details.
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 search tool with 6 parameters, 0% schema coverage, no annotations, and no output schema, the description provides comprehensive parameter documentation and behavioral context. It lacks details on return format (what fields are included in results) and error cases, but covers most essential usage aspects adequately.
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 description coverage is 0%, so the description must compensate fully. It provides detailed semantics for all 6 parameters: query syntax examples for 'q', pagination details for 'page' and 'page_size', sorting syntax for 'order', deduplication options for 'unique', and language preference for 'priority_chinese'. This adds significant value beyond the bare 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 cards via query string). It specifies the exact action (search) and resource (cards), distinguishing it from siblings like get_card_by_set_and_number (specific card retrieval) or get_set_cards (cards within a set).
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 implies usage through query syntax examples but doesn't explicitly state when to use this tool versus alternatives like get_set_cards or get_card_by_set_and_number. It provides context for search functionality but lacks explicit guidance on tool selection among siblings.
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:

[![1777316659870723 MCP server](https://glama.ai/mcp/servers/xiaobenyang-com/1777316659870723/badges/card.svg)](https://glama.ai/mcp/servers/xiaobenyang-com/1777316659870723)

Score Badge

Copy to your README.md:

[![1777316659870723 MCP server](https://glama.ai/mcp/servers/xiaobenyang-com/1777316659870723/badges/score.svg)](https://glama.ai/mcp/servers/xiaobenyang-com/1777316659870723)

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/xiaobenyang-com/1777316659870723'

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