Arknights Intelligence MCP

Server Quality Checklist

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

Latest release: v0.2.0
Disambiguation4/5
Most tools have clearly distinct purposes (e.g., get_enemy vs get_operator), but search_entities and search_stages overlap partially, potentially causing confusion.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern in snake_case (e.g., get_enemy, search_stages, analyze_stage), making them predictable.
Tool Count5/5
With 13 tools covering operators, enemies, stages, drops, announcements, banners, and data sources, the count feels well-scoped for the domain.
Completeness4/5
The set covers key lifecycle operations (CRUD, search, analysis), but lacks a direct get_item tool for item details, which is a minor gap.
Average 4.4/5 across 13 of 13 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 225 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
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

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, idempotent, non-destructive. The description adds context that it does not expose secrets, local paths, or OAuth config, which is valuable behavioral info beyond the 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that front-loads the action and lists fields efficiently. Every word adds value; no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool with no parameters and no output schema, the description adequately explains what is returned. Could mention if there are limits or filtering, but not strictly necessary.
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?
No parameters exist, and schema coverage is 100%. Baseline is 3, and the description adds no extra parameter guidance since there are none.
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 lists the public-safe source registry and enumerates the fields returned (id, owner, canonical URL, etc.), distinguishing it from sibling tools that list other entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs siblings like get_data_status or search_entities. The phrase 'public-safe' implies a scope, but no direct comparison or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds rich behavioral context beyond the annotations (readOnlyHint, idempotentHint, destructiveHint). It explains field conventions (list vs omitted, never null), the conditional inclusion of image_refs, and the fact that en/cn never mix. This fully discloses behavior and matches annotations.
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 fairly long and includes detailed field conventions, which are valuable but could be more concise. It front-loads the main action but then goes into edge cases. Some sentences could be trimmed without losing meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (no output schema, multiple fields), the description covers what the tool returns, field conventions, and conditional image behavior. It is largely complete for an agent to understand the tool's output, though an explicit example or note about required parameters would enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. While it mentions 'region + game_id' and the tool's purpose, it does not explicitly describe each parameter's meaning or constraints beyond the schema titles. The description adds some context but could be more detailed on parameter semantics.
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 starts with 'Fetch one Arknights enemy's facts by region + game_id', which is a specific verb and resource. It lists the detailed attributes returned, making it clear what the tool does. It distinguishes itself from sibling tools like 'get_operator' (focused on operators) and 'search_entities' (broader search).
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 the tool is used to get enemy details, but it does not explicitly state when to use this tool versus alternatives like 'search_entities' or 'get_stage'. There is no mention of exclusions or prerequisites (e.g., knowing the game_id). The guidance is implied but not comparative.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds valuable behavioral details: drop_rate is expected items per run (not probability), expired drops are still returned flagged data_stale, and include_efficiency adds deterministic observations. No contradiction with annotations.
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 informative but somewhat lengthy (multiple sentences). It front-loads the core purpose but then delves into detailed data structure explanations that could be streamlined. Not excessively verbose, but could be tighter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, no output schema, and 0% schema description coverage, the description covers the tool's behavior comprehensively: input parameters, output semantics (drop_rate meaning, provenance, expired flag, efficiency), and caching. It leaves no major gaps for an agent to misinterpret.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains server region, the two alternative identifiers (stage_code, game_id), and include_efficiency's purpose (add deterministic farming observations). It also clarifies computed fields like drop_rate and times. This provides sufficient meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches one Arknights stage's item drop rates by region and stage_code or game_id, sourced from Penguin Statistics cache. It specifies the resource (stage drops) and distinguishes from siblings like get_item_drops by focusing on stage-level data.
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 explains the input requirements (region + stage_code or game_id) and notes that en/cn are never mixed, but it does not explicitly guide when to use this tool versus alternatives like get_item_drops or search_stages. Usage is implied but not compared.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description provides extensive behavioral details beyond the readOnlyHint and idempotentHint annotations, including default response structure, optional include flags behavior, tile grid and enemy route conventions, field omission rules, and limitations like large map handling. No contradiction with annotations.
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 lengthy but front-loaded with the core purpose. Each sentence adds value, covering many technical details. It could be structured with bullet points for readability, but the current paragraph form is acceptable given the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 9 parameters and no output schema, the description is exceptionally complete. It explains the return format in detail, including tile grid, enemy routes, spawns, map image, field conventions, and edge cases like omitted fields and large map handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by explaining each parameter's purpose: server, game_id, stage_code, and all include flags (map, routes, spawns, map_image). It also clarifies pagination via routes_page and spawns_page, making all parameters meaningful.
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 fetches a single Arknights stage's facts by region and stage_code or game_id. It specifies the resource and identifiers, but does not explicitly differentiate from sibling tools like search_stages or analyze_stage, which could also be used for stage-related queries.
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 explicit guidance on when to use this tool versus alternatives. The description assumes the user wants a single stage's facts but does not provide criteria for selection or exclusions.
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?
Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds that observations are facts-only and never recommendations, and explains depth scaling. This adds context beyond annotations without contradiction.
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 two sentences: first covering purpose and output structure, second covering depth and server mixing. It is front-loaded and concise, though some detail like output rule_id could be more prominent.
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?
The description covers output structure (rule_id, evidence, confidence, limitations) and depth levels in detail. However, it does not clarify precedence between game_id and stage_code when both are provided, or the exact mapping of server to stage region. Overall sufficient for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description fully compensates by explaining each parameter: depth variants with detailed examples, server exclusivity (en/cn never mixed), and usage of stage_code (by region+code) and game_id. Examples like '4-4' clarify input format.
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 analyzes an Arknights stage into deterministic, evidence-backed threat observations. The verb 'Analyze' is specific, and the resource 'Arknights stage' is distinct from sibling tools that focus on data retrieval or search.
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 when threat observations are needed, but does not explicitly contrast with sibling tools like get_stage or search_stages. No when-to-use or when-not-to-use guidance is provided, leaving the agent to infer context.
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?
Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds valuable context: it warns about missing snapshots or entities, notes that en/cn are never mixed, and details the response contents beyond what annotations convey.
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 paragraph that is relatively concise but covers all necessary aspects. It could be more structured (e.g., bullet points) for easier parsing, but it is not verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and no output schema, the description fully explains what the tool returns: schema version, deployment mode, snapshot details per region, and warnings. It is complete for the tool's purpose.
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 coverage. Baseline for 0 parameters is 4; the description does not need to explain parameters and provides no param-specific information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reports the active build's data status, including schema version, deployment mode, and snapshot details per region. It distinguishes from sibling tools like search_entities or get_stage by focusing on overall data freshness and build configuration.
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 for checking data freshness and potential issues (e.g., missing snapshots), but does not explicitly compare to sibling tools or state when to use versus alternatives. No direct guidance on when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds extensive behavioral context: cache source, drop_rate meaning, provenance handling, stale data behavior, and ranking limitations. No contradictions with annotations.
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 lengthy but every sentence adds value. It is well-structured, front-loaded with the purpose, and logically organized. Minor redundancy could be trimmed, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 parameters, no output schema), the description comprehensively explains output fields, provenance, paging, ranking behavior, and data staleness. It addresses edge cases and limitations, making the tool's behavior fully predictable.
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 0%, so the description must compensate. It explains include_efficiency and pagination behavior in detail, but does not explicitly describe each parameter (e.g., server, game_id, page parameters). The description adds significant value but lacks full parameter mapping.
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 compares where an Arknights item drops by region and item game_id. It uses specific verbs ('compare', 'lists') and distinguishes from sibling tools (e.g., get_stage_drops for stage-specific drops).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (comparing drops across regions) and explicitly mentions limitations (stage availability, first-clear bonuses, byproducts not modeled). It does not directly contrast with siblings but provides sufficient context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, idempotent, non-destructive. Description adds valuable details: no body/html/prose returned, en/cn never mixed, returns empty list if feed not imported, results newest-first and paged. These go beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is a single sentence with good information density. It could be split for readability, but it remains concise 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description covers returned fields, region, date filtering, pagination, and behavior for missing data. Missing error handling or rate limits, but adequate for a read-only tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, so description compensates by explaining since/until are ISO date bounds, pagination with page/page_size, and the server enum. It doesn't detail nested page object fields, but the explicit mention of paging provides adequate guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states it lists official Arknights announcement metadata by region (en/cn), and distinguishes that it only returns metadata (announce_id, title, date, url, category) not body. This clearly differentiates from sibling tools which focus on enemies, operators, stages, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It indicates the tool is for listing announcement metadata from official news feeds, and that regions are never mixed. It doesn't explicitly state when not to use it, but the context of sibling tools makes the intended use clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint, idempotentHint, destructiveHint) already indicate safe behavior. The description goes further by disclosing limitations (absence of typed operators for standard banners, no pull-probability/pity/spark, and the fact that missing data is reported as a limitation, never fabricated). This fully meets behavioral transparency.
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 thorough but slightly verbose; it contains multiple compound sentences. It is well-structured, front-loading the main purpose, then detailing inclusions, exclusions, limitations, parameters, and pagination. Nearly every sentence adds value, though some could be condensed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description fully explains the return value structure (fields included and excluded, image_refs condition). It also covers parameter behavior, sorting, and limitations. All necessary context for an agent to use the tool effectively is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must explain parameters. It defines server as en/cn, since/until as ISO open-time bounds (inclusive), query as case-insensitive substring match on display name, and page/page_size for pagination. All five parameters are thoroughly described.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists Arknights banner archive metadata by region, enumerates the specific fields included (pool id, name, schedule, rule type, featured operators) and explicitly excludes unrelated data (gacha summary, html, images), which distinguishes it from any sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that results are newest-first and paged, and that standard banners lack typed featured operators. It does not explicitly reference sibling tools or state when not to use it, but the detailed scope makes usage context clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, idempotent, non-destructive. The description adds key behavioral traits: returns ranked region-tagged locators, only stage locators have stage_code/difficulty tag, results bounded (default 10, max 50), en/cn never mixed. No contradiction.
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 dense but efficient, with front-loaded main action and no wasted sentences. Slightly verbose but every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description covers return types (locators with region tags, stage-specific fields), bounds, and cross-language behavior. Could be improved by explicitly stating return shape for each entity type.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage. The description provides context for each parameter: query is search term, limit is bounded, server controls locale mixing, entity_type filters. However, it does not explain parameter formats or constraints per parameter directly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches indexed Arknights entities (operators, enemies, stages, items) by various criteria. It distinguishes from siblings by directing users to get_* tools for full facts and search_stages for stage codes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly explains when to use alternatives: get_operator/get_enemy/get_stage for full facts, get_item_drops from item locators, and search_stages for exact stage codes. No ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent. The description adds extensive behavioral details: per-level stat bonuses, trait/talent changes, upgrade costs, present=false for undefined levels, collapsed identical entries, bundle handling, token-applies-to, and template/blackboard data. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with main purpose, then detailed behavioral notes. While lengthy, every sentence provides necessary detail for a complex tool. Could be slightly more compact but well-organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description thoroughly explains the return structure: per-level side-by-side comparison, present=false, trait/talent formatting, bundle handling, mode output differences, and glossary reference. Complete for informed use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%; description fully compensates by explaining each parameter's meaning and constraints: mode (facts_only vs with_observations), levels (subset of 1/2/3, default all three), server (en/cn), game_id (string). Adds value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool compares one operator's modules across specified levels by region and game_id. It distinguishes from sibling get_operator, which returns the full kit. The verb 'compare' and resource 'operator modules' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use get_operator for full kit and this tool for level-by-level comparison. Also notes en/cn never mixed and provides context for mode selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses many behavioral traits beyond the annotations (readOnlyHint, idempotentHint): default response structure, when image_refs appear, language mixing rules, skill/talent/module effect handling, template emission conventions, and module change collapsing. No contradictions with annotations.
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 long but well-structured and front-loaded with the core purpose. Every sentence adds value, though a slight tightening could improve conciseness. It remains highly informative without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters, no output schema, and the complexity of the data, the description covers default behavior, optional sections, image refs, language handling, effect template details, module collapsing, token talent, and sibling tool alternative. It is complete for correct invocation and interpretation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by explaining the purpose and effect of each include parameter (phases, skills, talents, modules, summary, provenance) and the image_refs condition. It clarifies the meaning of server and game_id as region+game_id.
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 starts with a clear verb+resource: 'Fetch one Arknights operator's facts by region + game_id.' It explicitly states the tool's function and distinguishes it from siblings like search_entities (search) and compare_operator_modules (comparison).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool and when to use alternatives: 'To compare one operator's modules across their upgrade levels side by side, or for evidence-backed module observations, use compare_operator_modules instead.' It also explains which optional parameters to include for specific data sections.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, non-destructive. Description adds rich behavioral details: exact match ranking, difficulty variant tags, bounded results, and locale separation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with core action, each sentence adds essential information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, description adequately explains return format (ranked, region-tagged locators with difficulty tags), input behavior, and referral to get_stage for full data. Complete for this tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, description compensates fully: explains query types, limit bounds (default 10, max 50), and server behavior (never mixing en/cn). All three parameters are clearly described.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool searches Arknights stages by multiple identifiers (code, name, game id) and distinguishes from get_stage by noting that search returns locators while get_stage provides full facts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly directs users to use get_stage for full details, and notes that en/cn are never mixed, guiding server usage. Provides clear context for when to use this tool.
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:

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

Score Badge

Copy to your README.md:

[![arknights-mcp MCP server](https://glama.ai/mcp/servers/rendyuwu/arknights-mcp/badges/score.svg)](https://glama.ai/mcp/servers/rendyuwu/arknights-mcp)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/rendyuwu/arknights-mcp'

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