Cyphers MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Every tool has a clearly distinct purpose with no ambiguity. Tools are organized by resource type (battleitems, characters, images, matches, players, ranking) and specific actions (get, multi_get, search, list, url, matches, ranking types), making it easy for an agent to select the correct one without confusion.
Naming Consistency5/5
All tool names follow a consistent 'cy_resource_action' pattern using snake_case throughout. The naming convention is predictable and readable, with no deviations in style or structure across the 13 tools.
Tool Count5/5
With 13 tools, the count is well-scoped for a game-related server covering items, characters, images, matches, players, and rankings. Each tool earns its place by addressing specific needs without being overwhelming or insufficient for the domain.
Completeness4/5
The tool surface provides comprehensive coverage for querying and retrieving data across multiple game domains, with minor gaps such as no update or delete operations (which may be intentional for a read-only API) and no direct character detail lookup beyond listing. Agents can work around these with the available tools.
Average 2.8/5 across 13 of 13 tools scored. Lowest: 2.1/5.
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 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action '검색합니다' (searches), which implies a read operation, but lacks details on permissions, rate limits, pagination, or output format. This is insufficient for a tool with 6 parameters and no output schema, leaving significant 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 a single, concise sentence ('아이템을 검색합니다'), which is efficient but under-specified. While it avoids unnecessary words, it fails to provide essential context, making it feel incomplete rather than optimally concise. It could benefit from more detail to justify its brevity.
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 (6 parameters, no annotations, no output schema, and multiple sibling tools), the description is incomplete. It doesn't explain the return values, how results are filtered or ordered, or differentiate from similar tools. This leaves the agent with insufficient context to use the tool effectively, especially without annotations or output schema to fill gaps.
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 description coverage is 100%, with each parameter clearly documented in the input schema. The description adds no additional meaning beyond the schema, such as explaining relationships between parameters (e.g., how 'characterId' interacts with 'itemName'). However, the baseline score is 3 since the schema adequately covers parameter semantics without needing compensation from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '아이템을 검색합니다' (searches for items) states a basic purpose but is vague and tautological—it essentially restates the tool name 'cy_battleitems_search'. It doesn't specify what type of items (e.g., battle items in a game context) or distinguish from sibling tools like 'cy_battleitems_get' or 'cy_battleitems_multi_get', leaving ambiguity about scope and differentiation.
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any context, prerequisites, or exclusions, and fails to differentiate from sibling tools such as 'cy_battleitems_get' or 'cy_players_search', leaving the agent without direction on appropriate usage scenarios.
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 the tool generates a URL, implying a read-only operation that returns a resource, but does not disclose details like authentication needs, rate limits, error conditions, or what the generated URL represents (e.g., a direct image link, API endpoint). For a tool with no annotations, this leaves significant 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.
Conciseness4/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 for a simple tool, though it could be more informative. There is no structural issue, but it lacks depth that might warrant additional sentences for clarity.
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 has no annotations, no output schema, and a simple input schema, the description is incomplete. It does not explain what the generated URL is used for, any dependencies, or output details (e.g., URL format, image type). For a tool that generates resources, more context is needed to ensure proper use without structured data to fill gaps.
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 no parameter semantics beyond what the input schema provides. Schema description coverage is 100%, with clear documentation for 'characterId' and 'zoom' (including range for zoom). Since the schema fully describes parameters, the baseline score is 3, as the description does not compensate but also does not detract from the schema's completeness.
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 states the tool's purpose ('캐릭터 이미지 URL을 생성합니다' translates to 'Generates character image URL'), which is clear but basic. It specifies the verb ('생성합니다' - generates) and resource ('캐릭터 이미지 URL' - character image URL), but does not differentiate from sibling tools like 'cy_images_item_url' (which likely generates item image URLs) or explain scope beyond the literal translation. The purpose is understandable but lacks specificity about what makes this tool unique.
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 does not mention sibling tools (e.g., 'cy_images_item_url' for items vs. characters, or 'cy_characters_list' for listing characters), prerequisites, or exclusions. Usage is implied only by the tool name and description, with no explicit context for selection among related 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?
With no annotations provided, the description carries full burden for behavioral disclosure. It states what the tool does (generates URLs) but doesn't reveal any behavioral traits - no information about whether this requires authentication, rate limits, what format the URL returns, whether it's a read-only operation, or any side effects. For a tool with zero 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 extremely concise - a single Korean sentence that directly states the tool's function. There's zero wasted verbiage and it's front-loaded with the core purpose. It could potentially benefit from slightly more context, but as a standalone statement it's efficient.
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 no annotations, no output schema, and a simple single-parameter tool, the description is incomplete. It doesn't explain what the generated URL looks like, whether it's a direct image link or requires additional processing, what authentication might be needed, or how this relates to the sibling character URL tool. For even a simple tool, more context would be helpful.
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 description coverage is 100% with the single parameter 'itemId' well-documented in the schema. The description doesn't add any parameter semantics beyond what the schema already provides - it doesn't explain what constitutes a valid itemId, format requirements, or where to obtain itemIds. Baseline 3 is appropriate when schema does the heavy lifting.
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 states the purpose as 'generates item image URL' which is a clear verb+resource combination. However, it doesn't distinguish this tool from its sibling 'cy_images_character_url' which appears to serve a similar function for character images rather than item images. The purpose is understandable but lacks sibling differentiation.
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. There's no mention of prerequisites, when-not-to-use scenarios, or how this differs from other image-related tools like 'cy_images_character_url'. The agent must infer usage from the tool name alone.
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 only states that it retrieves ranking data, without mentioning whether this is a read-only operation, if it requires authentication, rate limits, or what the return format looks like. For a tool with no annotations, this is a significant gap in behavioral context.
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 single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized for a simple retrieval tool, though it could be slightly more informative without losing conciseness.
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 no annotations and no output schema, the description is incomplete. It doesn't explain what the ranking data includes, how it's structured, or any behavioral traits. For a tool with three parameters and ranking functionality, more context is needed to help the agent understand the full scope and usage.
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 description coverage is 100%, with all parameters documented in the schema (tsjType, offset, limit). The description adds no additional meaning about parameters beyond what the schema provides, such as explaining what '투신전' entails or how offset/limit affect results. Baseline 3 is appropriate since the schema does the heavy lifting.
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 states the purpose as '투신전 랭킹을 조회합니다' (retrieve 투신전 ranking), which is a clear verb+resource combination. However, it doesn't differentiate from sibling tools like 'cy_ranking_characters' or 'cy_ranking_ratingpoint', leaving ambiguity about what type of ranking this specifically provides. The purpose is understandable but lacks sibling distinction.
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?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention any context, prerequisites, or exclusions, and it doesn't reference sibling ranking tools to help the agent choose appropriately. This leaves the agent without usage direction.
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 only states that it retrieves rankings, without mentioning aspects like whether it's read-only, if it requires authentication, rate limits, pagination behavior (implied by offset/limit but not explained), or error handling. For a tool with 4 parameters and no annotations, this is a significant gap in transparency.
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 Korean that directly states the tool's function without unnecessary words. It's front-loaded and appropriately sized for its purpose, with no wasted text. This makes 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 has 4 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain the ranking system, return format, or behavioral traits. While conciseness is good, more context is needed for effective use, especially with sibling ranking tools that might overlap in functionality.
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 description coverage is 100%, with clear descriptions for all parameters (characterId, rankingType, offset, limit). The description adds no additional meaning beyond the schema, such as explaining valid values for rankingType or how offset/limit affect results. Since the schema is well-documented, the baseline score of 3 is appropriate, but the description doesn't enhance parameter understanding.
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 '캐릭터별 랭킹을 조회합니다' (Retrieves rankings by character) states the basic action (retrieve) and resource (character rankings), which is clear but vague. It doesn't specify what kind of rankings (e.g., competitive, popularity) or distinguish from sibling tools like cy_ranking_ratingpoint and cy_ranking_tsj, which also handle rankings. The purpose is understandable but lacks specificity.
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?
There is no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like cy_ranking_ratingpoint or cy_ranking_tsj, nor does it provide context such as prerequisites or exclusions. The description only states what it does, leaving the agent to infer usage from the tool name and parameters alone.
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 retrieval operation ('조회합니다'), implying it's likely read-only and non-destructive, but doesn't confirm this or address other aspects like authentication needs, rate limits, error handling, or response format. For a tool with no annotations, 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, clear sentence that efficiently conveys the tool's purpose without unnecessary words. It's front-loaded with the core action and resource, making it easy to understand at a glance. Every part of the sentence earns its place by specifying the key elements.
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 (simple retrieval with one parameter), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what 'detailed information' includes, how results are structured, or any behavioral traits like safety or performance. For a tool with no structured support, the description should provide more context to be fully helpful.
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 mentions '아이템 ID' (item ID), which aligns with the schema's parameter 'itemId' described as '아이템 ID.' With 100% schema description coverage, the schema already documents the parameter adequately. The description doesn't provide additional context like format examples or constraints, so it meets the baseline for high schema coverage.
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: '아이템 ID로 아이템 상세 정보를 조회합니다' translates to 'Retrieve detailed item information by item ID.' This specifies the verb (retrieve/조회), resource (item/아이템), and scope (detailed information/상세 정보). However, it doesn't explicitly differentiate from sibling tools like 'cy_battleitems_multi_get' or 'cy_battleitems_search,' which likely retrieve multiple items or search items respectively.
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 such as 'cy_battleitems_multi_get' for multiple items or 'cy_battleitems_search' for searching, nor does it specify prerequisites like needing a specific item ID. Usage is implied by the description but not explicitly stated.
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 mentions the batch size limit (30 items), which is useful behavioral context. However, it lacks details on permissions, rate limits, error handling, or the format of returned data. For a read operation with no annotation coverage, this leaves significant gaps in understanding how the tool behaves.
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 front-loads the core purpose and includes a key constraint (30-item limit). There is no wasted wording, and it is appropriately sized for the tool's complexity.
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 no annotations and no output schema, the description is incomplete. It covers the basic purpose and batch limit but omits critical details like return format, error conditions, or how results are structured. For a tool that retrieves multiple items, more context on output behavior is needed to be fully helpful.
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 input schema has 100% description coverage, with the parameter 'itemIds' fully documented in the schema. The description adds no additional semantic context about parameters beyond implying batch retrieval. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, as the description does not compensate with extra insights.
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: '여러 아이템의 상세 정보를 한 번에 조회합니다' (retrieves detailed information for multiple items at once). It specifies the verb '조회합니다' (retrieve/look up) and resource '아이템의 상세 정보' (detailed item information), but does not explicitly differentiate from sibling tools like cy_battleitems_get (which likely retrieves single items).
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 a limit of 30 items but does not specify scenarios where batch retrieval is preferred over single-item lookups (e.g., cy_battleitems_get) or search operations (e.g., cy_battleitems_search). No prerequisites or exclusions are stated.
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 only states the retrieval action without mentioning whether this is a read-only operation, if it requires authentication, rate limits, error conditions, or what the output format might be. For a tool with no annotation coverage, this is a significant gap in transparency.
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 or redundancy. It's appropriately sized and front-loaded, making it easy for an agent 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 lack of annotations and output schema, the description is incomplete. It doesn't address behavioral aspects like safety, permissions, or response format, which are crucial for a retrieval tool. While the parameter is well-covered, the overall context for effective tool use is insufficient.
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 schema description coverage is 100%, with the single parameter 'matchId' documented in the schema. The description adds minimal value by implying the parameter is used for lookup ('매치 ID로'), but doesn't provide additional context like format examples or constraints beyond what the schema already states, meeting the baseline for high coverage.
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 with a specific verb ('조회합니다' - retrieve/look up) and resource ('매칭 상세 정보' - match details), and identifies the key input ('매치 ID로' - by match ID). However, it doesn't differentiate from sibling tools like 'cy_players_matches' which might also retrieve match-related data, preventing a perfect score.
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 prerequisites, exclusions, or comparisons to sibling tools (e.g., 'cy_players_matches' for player-specific matches or 'cy_battleitems_get' for item details), leaving the agent with no usage context beyond the basic purpose.
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 retrieval operation ('조회'), implying it's likely read-only and non-destructive, but doesn't confirm this or address other behavioral aspects like authentication needs, rate limits, error handling, or response format. For a tool with zero annotation coverage, this is a significant gap in transparency.
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's appropriately sized for a simple lookup tool and front-loaded with the core functionality. Every part of the sentence earns its place by specifying the action, input, and output.
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 lack of annotations and output schema, the description is incomplete. It doesn't explain what '상세 정보' (detailed information) includes, such as player stats, level, or other attributes, which the agent would need to understand the tool's utility. For a retrieval tool with no structured output documentation, more context on return values is needed to be complete.
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 schema description coverage is 100%, with the parameter 'playerId' fully documented in the schema as '플레이어 ID'. The description adds no additional semantic context beyond what's in the schema (e.g., format examples, validation rules, or relationship to other data). According to the rules, with high schema coverage, the baseline is 3 even without param info in the description.
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: '플레이어 ID로 플레이어 상세 정보를 조회합니다' (Retrieves detailed player information using player ID). It specifies the verb (조회/retrieve), resource (플레이어 상세 정보/player detailed information), and key input (player ID). However, it doesn't explicitly differentiate from sibling tools like cy_players_search or cy_players_matches, which also involve player 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 sibling tools like cy_players_search (which might search by name instead of ID) or cy_players_matches (which might retrieve match history), leaving the agent to infer usage from the name alone. There's no explicit when/when-not or alternative tool recommendations.
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 only states it's a retrieval operation ('조회합니다'), but doesn't mention any behavioral traits like pagination (implied by the 'next' parameter), rate limits, authentication needs, or what the return format looks like. This is a significant gap for a tool with 6 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Korean that directly states the tool's purpose without any fluff or redundancy. It's appropriately sized and front-loaded, making it easy for an agent 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 complexity (6 parameters, no output schema, no annotations), the description is incomplete. It doesn't explain the return values, pagination behavior, or any constraints beyond what's implied in the schema. For a retrieval tool with multiple filtering options, more context is needed to help the agent use it effectively.
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 input schema has 100% description coverage, so the schema already documents all parameters thoroughly. The description adds no additional meaning beyond what's in the schema, such as explaining relationships between parameters (e.g., date range constraints) or usage examples. Baseline 3 is appropriate when the schema does the heavy lifting.
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 as 'retrieves player match records' (플레이어의 매칭 기록을 조회합니다), which is a specific verb+resource combination. However, it doesn't distinguish this from sibling tools like 'cy_matches_get' or 'cy_players_get', which might have overlapping functionality, so it doesn't reach the highest score.
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. With sibling tools like 'cy_matches_get' and 'cy_players_get' available, there's no indication of context, prerequisites, or exclusions, leaving the agent to guess based on the tool name alone.
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. While it implies a read-only search operation, it doesn't cover important aspects like rate limits, authentication needs, error handling, or the format of search results. For a tool with no annotation coverage, this is a significant gap in transparency.
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 unnecessary words. It's front-loaded with the core functionality and avoids redundancy, making it easy to parse and understand 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?
For a search tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the search returns (e.g., player details, IDs), how results are ordered, or any limitations beyond the schema. This leaves gaps in understanding the tool's full behavior and output, especially given the lack of structured output information.
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 input schema has 100% description coverage, with clear documentation for all three parameters (nickname, wordType, limit). The description doesn't add any additional semantic details beyond what the schema provides, such as examples or usage tips. Given the high schema coverage, a baseline score of 3 is appropriate as the schema handles the parameter documentation adequately.
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: 'search for players by nickname' (닉네임으로 플레이어를 검색합니다). It specifies both the action (search) and the resource (players), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like cy_players_get, which might fetch a specific player rather than search.
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, context for usage, or compare it to sibling tools such as cy_players_get or cy_players_matches. This lack of comparative information leaves the agent without clear direction on tool 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?
With no annotations provided, the description carries full burden for behavioral disclosure. It only states it retrieves data without describing response format, pagination behavior (though offset/limit parameters suggest pagination), error conditions, or performance characteristics. For a read operation with 4 parameters, this leaves significant 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Korean that directly states the tool's purpose. There's no wasted language or unnecessary elaboration - every word contributes to understanding what the tool does.
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 4 parameters, no annotations, and no output schema, the description is insufficiently complete. It doesn't explain what 'integrated ranking/rating points' means, how results are structured, whether all parameters are optional (as indicated by required: []), or what happens when multiple filtering parameters are provided together.
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 description coverage is 100%, so the schema fully documents all 4 parameters. The description adds no additional parameter context beyond what's in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no parameter information in the description.
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 action ('조회합니다' - retrieves/queries) and the resource ('통합 랭킹(레이팅 포인트)' - integrated ranking/rating points). It distinguishes from some siblings like cy_battleitems_get or cy_characters_list by specifying ranking data, but doesn't explicitly differentiate from cy_ranking_characters or cy_ranking_tsj which also retrieve ranking 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. There's no mention of when this ranking type is appropriate compared to cy_ranking_characters or cy_ranking_tsj, nor any prerequisites or constraints for usage.
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 only states what the tool does ('retrieves all character list') without describing any behavioral traits like pagination, rate limits, authentication requirements, data freshness, or what format the list returns. This leaves significant gaps for an agent to understand how to properly use this 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, efficient sentence that directly states the tool's purpose without any unnecessary words. It's appropriately sized for a simple list-retrieval tool with no parameters.
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 list-retrieval tool with no annotations and no output schema, the description is insufficient. It doesn't explain what the return value looks like (array format, fields included), whether there are limitations (max results, pagination), or any behavioral constraints. The agent would need to guess about the output structure and usage patterns.
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 tool has zero parameters with 100% schema description coverage, so the schema already fully documents the parameter situation. The description appropriately doesn't waste space discussing non-existent parameters. Baseline for zero parameters is 4, and the description doesn't detract from this.
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 action ('조회합니다' - retrieves/views) and resource ('모든 캐릭터 목록' - all character list). It's specific about retrieving a complete list rather than filtered results. However, it doesn't explicitly differentiate from sibling tools like 'cy_ranking_characters' which might also involve character 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?
No guidance is provided about when to use this tool versus alternatives. The description doesn't mention any prerequisites, context for usage, or comparison with sibling tools like 'cy_ranking_characters' or 'cy_players_get' that might also provide character-related information.
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:

[![CyphersMCPServer MCP server](https://glama.ai/mcp/servers/DHKim327/CyphersMCPServer/badges/card.svg)](https://glama.ai/mcp/servers/DHKim327/CyphersMCPServer)

Score Badge

Copy to your README.md:

[![CyphersMCPServer MCP server](https://glama.ai/mcp/servers/DHKim327/CyphersMCPServer/badges/score.svg)](https://glama.ai/mcp/servers/DHKim327/CyphersMCPServer)

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/DHKim327/CyphersMCPServer'

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