Skip to main content
Glama
rendyuwu

Arknights Intelligence MCP

by rendyuwu

Get stage

get_stage
Read-onlyIdempotent

Fetch an Arknights stage's compact facts and provenance by region and stage code or game ID. Optionally include tile grid, enemy routes, spawn timeline, or rendered SVG map.

Instructions

Fetch one Arknights stage's facts by region + stage_code (e.g. 4-4) or game_id. The default response is compact facts + provenance; set include_map / include_routes / include_spawns to add the tile grid, enemy routes, or spawn timeline. The tile grid comes as tile_grid: one string per grid row (top row first) plus a legend mapping each character to its tile fields; absent_symbol marks a cell with no tile. A tile's tile_key/buildable_type describe where you may DEPLOY (a tile_forbidden tile blocks deployment), while passable describes whether ENEMIES may cross it -- so a forbidden tile can still be passable; the two are not in conflict. Enemy routes are collapsed to distinct geometry: each entry carries an occurrence_count and the raw route_indices that share it. A checkpoint always carries type and position; its optional time, reach_distance, reach_offset and randomize_reach_offset fields are omitted when they sit at their zero/false default (omitted means at default). A spawn's variant_id (an inline enemy variant) is present only when the spawn is one; a base-enemy spawn omits the key. Spawn timeline values (spawn_time and interval) are in seconds. Set include_map_image for a rendered SVG map drawn from the stage's own grid data (a derived image, not game artwork); a very large map is omitted with a note. The difficulty field is the stage variant tag (NORMAL, FOUR_STAR challenge, TOUGH, or EASY), so a stage and its variant that share a code stay distinct. en/cn are never mixed. Field conventions: a list field is [] when the source confirms none, and is omitted entirely when the source carries no such data (never null). A field the response would normally include but the source omits is named in limitations.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
serverYes
game_idNo
stage_codeNo
include_mapNo
routes_pageNo
spawns_pageNo
include_routesNo
include_spawnsNo
include_map_imageNo
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.

Install Server

Other Tools

Latest Blog Posts

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