Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Arknights Intelligence MCP show me the stage info for 1-7"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Read-only Arknights intelligence exposed over the Model Context Protocol
(MCP) from one shared application core
across two transports — local stdio and a private, OAuth/OIDC-protected
Streamable HTTP endpoint — backed by versioned SQLite snapshots.
It answers structured stage/enemy and operator/module questions with region tagging, source provenance, and deterministic, evidence-backed analysis. User-facing tools query SQLite only; they never fetch upstream data at query time.
⚠️ Unofficial fan project. This is an unofficial, non-commercial, fan-made tool. It is not affiliated with, endorsed by, or sponsored by Hypergryph, Yostar, the maintainers of any upstream data source, Anthropic, or OpenAI. "Arknights" and all related names, logos, characters, artwork, audio, story text, and other game content are trademarks and/or copyrights of their respective rights holders. See
NOTICE.
v0.1 (private alpha, in development). Private and non-commercial. Public, multi-tenant hosting is explicitly out of scope and gated behind a separate readiness review — it cannot be enabled by a single configuration flag.
Related MCP server: AmiyaBot MCP Server
Stage & enemy intelligence — stage metadata, enemies, routes, waves, tiles, spawns, and a deterministic stage-threat analyzer with evidence.
Operator & module intelligence — operators, skills, talents, modules, and conservative, capability-based observations.
Regions: en and cn. Region-specific data is never silently mixed.
No query-time downloading or scraping — data comes from imported/synced snapshots only.
No game login, no credential handling, no player-roster storage.
No squad optimizer, combat simulator, or banner/gacha planning.
No bundled raw snapshots or prebuilt databases in releases.
The Apache-2.0 LICENSE covers project code only. Imported
game data and game content are separately governed — see NOTICE.
Please read, in particular:
DATA_SOURCES.md — the source registry: owner, URL,
purpose, fields consumed, region, license/permission posture, attribution,
enabled state, and last review for every source.
DATA_POLICY.md — field allowlist, excluded content,
no-bulk-export policy, and provenance requirements.
TAKEDOWN_POLICY.md — how to request attribution,
correction, source exclusion, or removal, and the disable/purge/rebuild
procedure.
PRIVACY.md — remote processing, minimal logging,
retention, and the no-credentials posture.
SECURITY.md — how to report vulnerabilities and the
runtime security posture.
stdio)The CLI subcommands land across milestones M1–M2; this section is the intended shape.
uv sync
# Build a local database from an approved local snapshot:
uv run arknights-mcp import --server en --source-path ./snapshot/en
# Serve over stdio for a local MCP host (Claude Code, Codex, ...):
uv run arknights-mcp serve --transport stdioFor client setup, see docs/clients/claude-code.md
(Claude Code) and docs/clients/codex.md (OpenAI
Codex). Both wire this server over local stdio using the current official MCP
config formats. For the private remote (Streamable HTTP) transport, see
docs/clients/remote.md — validating the authenticated
endpoint against the MCP Inspector, Claude connector, OpenAI API, and ChatGPT
web. See docs/ for architecture, adding a source, and adding a rule.
uv sync
uv run ruff check .
uv run ruff format --check .
uv run mypy
uv run pytest -qContributor and coding-agent guardrails live in AGENTS.md and
CLAUDE.md. The design of record is SPEC.md
(distilled from the PRD); the founder-approved decisions in the PRD are
binding and any change requires an ADR (see docs/adr/).
Apache-2.0 for project code only. See NOTICE for the
scope limitation and trademark/attribution notices.
Analyze one Arknights stage (by region + stage_code, e.g. 4-4, or game_id) into deterministic, evidence-backed threat observations: each carries a rule_id, typed evidence, a confidence score, and limitations -- facts and observations only, never a mandatory or best-in-slot recommendation. depth scales the surrounding facts: summary (observations only), standard (+ enemy roster + analyzer warnings), detailed (+ full per-enemy stat and timing context, with attack_interval and spawn times in seconds). en/cn are never mixed.
| Name | Required | Description | Default |
|---|---|---|---|
| depth | No | standard | |
| server | Yes | ||
| game_id | No | ||
| stage_code | No |
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.
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.
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.
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.
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.
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.
Compare one Arknights operator's modules across the requested module levels (a subset of 1/2/3, default all three) by region + game_id. Each module lists its per-level stat bonuses, trait changes, talent changes, and upgrade cost side by side; a level a module does not define is marked present=false. mode facts_only returns the comparison; with_observations adds deterministic, evidence-backed observations (never a mandatory or best-in-slot verdict). en/cn are never mixed. Each stat/trait/talent change includes the in-game effect description template (when present in the source) alongside raw blackboard key-value data; read the template to interpret the values, and do not infer mechanics from a key name alone. A module's trait template is emitted once as the module's trait_change_description when it is the same at every level; it appears on a level's trait change only when the wording differs between levels. For a module's trait_changes and talent_changes: repeated identical entries for one change are collapsed into a single row. A bundle that is the same at every level is listed once on the module (as trait_changes or talent_changes) and omitted from each level. A talent change tagged applies_to "token" affects the operator's summon or token rather than the operator. For an operator's full kit (identity, phases, skills, talents, and modules), use get_operator with include_modules. This tool instead compares modules level by level, and its with_observations mode adds evidence-backed observations. A glossary of common blackboard keys is provided in this server's instructions.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | facts_only | |
| levels | No | ||
| server | Yes | ||
| game_id | Yes |
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.
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.
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.
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.
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.
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.
List official Arknights announcement METADATA by region (en/cn), sourced from the official news feed: each entry carries only its announce_id, title, date, url, and category -- never the article body, html, or prose. Optional since/until bounds window the list by ISO date (inclusive); results are newest-first and paged (bounded page/page_size). en/cn are never mixed. The announcement source is disabled by default, so a region with no imported feed returns an empty list.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| since | No | ||
| until | No | ||
| server | Yes |
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.
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.
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.
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.
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.
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.
List Arknights banner archive metadata by region (en/cn), sourced from the game data gacha_table. Each entry carries only its pool id, display name, open/end schedule, rule type, and the typed featured operators. It never carries gacha summary, detail, html, or image prose. A standard banner (NORMAL/SINGLE/DOUBLE/LINKAGE) carries no typed featured operator, because its rate-up is not in the typed game data. That absence is reported as a limitation, never fabricated. This is a historical schedule fact, not gacha planning. It has no pull-probability, pity, or spark. Optional since/until bounds window the list by ISO open-time (inclusive). An optional query narrows the list to banners whose display name contains that text (case-insensitive). Results are newest-first and paged (bounded page/page_size). When the image-reference source is enabled, a featured operator that resolved to a present operator also carries an image_refs list with its derived portrait and avatar URLs. Each ref carries a variant label (e0/e2 for portrait, base/e2 for avatar). en/cn are never mixed.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| query | No | ||
| since | No | ||
| until | No | ||
| server | Yes |
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.
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.
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.
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.
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.
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.
List the public-safe source registry: id, owner, canonical URL, purpose + consumed fields, region coverage, license/permission posture, attribution, and the active snapshot per region. No secrets, local paths, or OAuth config.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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.
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.
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.
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.
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.
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.
Report the active build's data status: schema + analyzer version, deployment mode, and the active snapshots per region (source, commit/version, and age in days so the client can judge freshness). Each snapshot's region, id, and import time travel with the response provenance, one entry per snapshot in order. Warns when the active build has no snapshots or no imported entities, with a suggested admin action. en/cn are never mixed.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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.
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.
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.
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.
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.
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.
Fetch one Arknights enemy's facts by region + game_id: class, boss/elite flags, attack/motion type, and the per-level stat block (hp, atk, def, res, attack interval in seconds, attack range, move speed, weight, life-point reduction) with immunities and abilities. When the image-reference source is enabled, an additional image_refs list with the derived enemy sprite URL is included; each ref carries a variant label (the enemy sprite is variant base). 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.
| Name | Required | Description | Default |
|---|---|---|---|
| server | Yes | ||
| game_id | Yes |
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.
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.
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.
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.
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.
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.
Compare where one Arknights item drops by region + item game_id, sourced from the Penguin Statistics cache. It lists the item's drop across every stage that yields it. Each stage carries its sanity cost, quantity, times, and drop_rate. The times is the sample run count. The drop_rate is the expected number of items per run (quantity divided by times), not a probability. The penguin provenance (snapshot, fetched/expires time, and import time) shared by every stage is hoisted to a single drop_provenance block. A stage repeats a provenance field only when it differs. A stage carries expired:true only when past its cache expiry. Set include_efficiency to add deterministic farming observations, ranked ascending by sanity spent per item. With that flag the ranked observation is the single per-stage list, each row folding the stage facts and its sanity-per-item, so the stages are never listed twice. Without the flag the raw stages list is returned and paged on its own. That ranking is an ordering and evidence, never a best-farm or mandatory verdict. Stage availability, first-clear bonuses, and byproducts/synthesis are not modeled. A stage drop past its expiry is still returned, flagged data_stale. It is downgraded in the ranking, not dropped. A re-sync of the penguin source refreshes the cache. An item's comparison never mixes en/cn stages.
| Name | Required | Description | Default |
|---|---|---|---|
| server | Yes | ||
| game_id | Yes | ||
| stages_page | No | ||
| efficiency_page | No | ||
| include_efficiency | No |
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.
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.
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.
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.
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.
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.
Fetch one Arknights operator's facts by region + game_id. The default response is compact identity + a summary (rarity, profession, subclass, position, tags, and how many phases/skills/talents/modules exist) + provenance; set include_phases / include_skills / include_talents / include_modules to add each (bounded) heavy section. When the image-reference source is enabled, an additional image_refs list of derived portrait/avatar/skin art URLs is included. Each ref carries a variant label naming the art: e0 (base elite-0), e2 (elite-2), base (avatar), or skin. en/cn are never mixed. Skill, talent, and module effects include the in-game effect description template (when present in the source) alongside raw blackboard key-value data; read the template to interpret the values, and do not infer mechanics from a key name alone. A skill's template is emitted once as the skill's description when it is the same at every level; it appears on a level only when the wording differs between levels. For a module's trait_changes and talent_changes: repeated identical entries for one change are collapsed into a single row. A bundle that is the same at every level is listed once on the module (as trait_changes or talent_changes) and omitted from each level. A talent change tagged applies_to "token" affects the operator's summon or token rather than the operator. To compare one operator's modules across their upgrade levels side by side, or for evidence-backed module observations, use compare_operator_modules instead. A glossary of common blackboard keys is provided in this server's instructions.
| Name | Required | Description | Default |
|---|---|---|---|
| server | Yes | ||
| game_id | Yes | ||
| include_phases | No | ||
| include_skills | No | ||
| include_modules | No | ||
| include_summary | No | ||
| include_talents | No | ||
| include_provenance | No |
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.
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| server | Yes | ||
| game_id | No | ||
| stage_code | No | ||
| include_map | No | ||
| routes_page | No | ||
| spawns_page | No | ||
| include_routes | No | ||
| include_spawns | No | ||
| include_map_image | No |
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.
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.
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.
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.
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.
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.
Fetch one Arknights stage's item drop rates by region + stage_code (e.g. 4-4) or game_id, sourced from the Penguin Statistics cache. Each drop carries its quantity, its times, and its drop_rate. The times is the sample run count. The drop_rate is the expected number of items per run (quantity divided by times), not a probability. The penguin provenance (snapshot and fetched/expires time) shared by every drop is hoisted to a single drop_provenance block. A drop repeats a provenance field only when it differs. A drop carries expired:true only when it is past its cache expiry. Set include_efficiency to add deterministic farming observations (sanity spent per item). Those are facts and observations only, never a best-farm or mandatory verdict. A drop past its expiry is still returned, flagged data_stale. A re-sync of the penguin source refreshes the cache. en/cn are never mixed.
| Name | Required | Description | Default |
|---|---|---|---|
| server | Yes | ||
| game_id | No | ||
| stage_code | No | ||
| include_efficiency | No |
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.
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.
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.
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.
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.
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.
Search indexed Arknights operators, enemies, stages, and items by name, alias, stage code, game id, or tag. Returns ranked, region-tagged locators; use get_operator / get_enemy / get_stage for full facts, or feed an item locator's game_id to get_item_drops. Only a stage locator carries stage_code and a difficulty variant tag (NORMAL, FOUR_STAR challenge, TOUGH, or EASY); other locators omit both keys. The difficulty tag lets a normal stage and its challenge, tough, or easy variant that share a code and name stay distinguishable. For a stage code like 4-4, prefer search_stages, which ranks an exact stage-code match first. Results are bounded (default 10, max 50) and en/cn are never mixed.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | ||
| server | No | ||
| entity_type | No |
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.
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.
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.
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.
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.
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.
Search indexed Arknights stages by stage code (e.g. 4-4), name, or game id. An exact stage-code match is ranked first. Returns ranked, region-tagged locators; use get_stage for full facts + map/spawns. Each locator carries a difficulty variant tag (NORMAL, FOUR_STAR challenge, TOUGH, or EASY), so a normal stage and its challenge, tough, or easy variant that share a code and name stay distinguishable. Results are bounded (default 10, max 50) and en/cn are never mixed.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | ||
| server | No |
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.
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.
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.
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.
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.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.2.0analyze_stagecompare_operator_modulesget_announcementsget_bannersget_data_sourcesget_data_statusget_enemyget_item_dropsget_operatorget_stageget_stage_dropssearch_entitiessearch_stagesScored across 13 tools
Most tools have clearly distinct purposes (e.g., get_enemy vs get_operator), but search_entities and search_stages overlap partially, potentially causing confusion.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., get_enemy, search_stages, analyze_stage), making them predictable.
With 13 tools covering operators, enemies, stages, drops, announcements, banners, and data sources, the count feels well-scoped for the domain.
The set covers key lifecycle operations (CRUD, search, analysis), but lacks a direct get_item tool for item details, which is a minor gap.
Read-only MCP server for The Quiet Protocol's engines, benchmarks, proof, and business data.
Query your org's data in natural language — read-only MCP access to SQL, NoSQL, files & warehouses.
Read-only MCP for the Eco game wiki: search, Markdown pages, and wiki_* lookups. No keys, no writes.
Governed data discovery, exact queries, decisions, simulations, and runtime utilities over MCP.
