Crowdsourced Arknights drop rates by stage and item, for the CN, US, JP and KR game servers
Scored across 6 tools
Each tool has a clearly distinct purpose: search_items and search_stages resolve IDs for different entity types, get_item_drop_rates and get_stage_drops query opposite directions of the same relation, list_events handles events, and get_dataset_info is metadata. There is no meaningful overlap that would cause an agent to misselect a tool.
All names follow a predictable snake_case verb_noun pattern using get_, list_, and search_ prefixes. The convention is consistent throughout and makes the action and target resource easy to infer.
Six tools are well-scoped for a read-only game statistics server: two search/lookup tools, two drop-query tools, an event lister, and a metadata tool. Every tool earns its place without redundancy or unnecessary breadth.
The surface covers the core workflows: find items and stages, query drops in both directions, list events, and read dataset metadata. A minor gap exists around historical event stage discovery, since list_events reports stage counts rather than stage IDs for closed events and there is no dedicated event search tool.
Describes the Penguin Statistics drop data: what its numbers mean (times, quantity, drop rate, sanity per item, window), the game servers with their time zones and how fresh the data of each is, the caveats, the license and how to credit it. Call it when unsure how to read or cite the numbers.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| docs | Yes | Documentation of the public API of Penguin Statistics |
| name | Yes | |
| source | Yes | |
| caveats | Yes | |
| license | Yes | |
| openapi | Yes | OpenAPI (Swagger 2.0) document of the public API |
| servers | Yes | |
| website | Yes | |
| licenseUrl | Yes | |
| definitions | Yes | |
| description | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true and openWorldHint=false, so safety is covered. The description adds useful behavioral context by disclosing the content scope, including freshness information per server and caveats, which an agent could not infer from the schema.
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?
One front-loaded sentence establishes the resource, and the enumeration of covered topics follows logically. The list of topics is long but each item is genuinely part of what the tool returns, so little could be cut without losing information.
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?
An output schema exists, so return values need not be spelled out, and the description already tells the agent what topical material the response contains. For a parameterless reference tool, nothing an agent needs before calling it is missing.
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 takes zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. The description does not need to compensate for any schema gap.
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 opens with a specific verb and resource ('Describes the Penguin Statistics drop data') and then enumerates exactly what the description covers (field meanings, servers/time zones/freshness, caveats, license). It is clearly distinct from the sibling tools, which return actual drop numbers rather than explaining them.
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?
'Call it when unsure how to read or cite the numbers' gives a clear triggering condition. It does not explicitly name the sibling tools as the alternative for retrieving data, but the split between metadata and data retrieval is easy to infer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns where to farm an item on a game server: the stages that drop it, with runs (times), quantity, drop rate (items per run) and sanity per item. By default the stages open now that still drop it, lowest sanity per item first; stages of fewer than 100 runs (lowSample) rank after the others, gachas and the recruitment (no sanity cost) last. sort_by=drop_rate ranks by rate instead; include_closed=true adds past events and ended drops. Takes the item ID from search_items.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Language of the names in the result: zh, en, ja or ko. Default en. | en |
| top_n | No | Most stages to return, 1 to 100. Default 10. | |
| server | No | Game server: CN (China), US (global, English), JP (Japan) or KR (Korea). Default CN. | CN |
| item_id | Yes | Item ID, from search_items: 30012. A name or alias that only one item has works too: 固源岩, Orirock Cube | |
| sort_by | No | sanity_per_item (default): the least sanity per item first. drop_rate: the most items per run first. | sanity_per_item |
| include_closed | No | false (default): only the stages open on the server now that still drop the item. true: also the stages of past events and the drops that ended, for history. |
| Name | Required | Description |
|---|---|---|
| item | Yes | |
| note | No | |
| rows | Yes | The stages, in the order of sortBy |
| server | Yes | |
| sortBy | Yes | |
| source | Yes | |
| dataAsOf | No | When the drop data was calculated, RFC 3339 in UTC |
| returned | Yes | |
| truncated | Yes | Whether top_n left out stages |
| definitions | Yes | |
| totalStages | Yes | Stages that drop the item now (dropsNow), or all with includeClosed |
| includeClosed | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already carry readOnly/idempotent safety, and the description adds genuinely useful behavior: default ranking by sanity per item, low-sample stages demoted, gachas and recruitment ranked last, and what include_closed actually pulls in. It does not discuss empty results or error behavior, but the ordering semantics are a real contribution.
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 what is returned before the ranking and mode caveats, and no sentence is filler. The middle clause chain is dense but each clause carries distinct information about ordering behavior.
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?
With an output schema present, the description needn't explain return shapes; it covers defaults, ordering, closed-stage handling, and the prerequisite lookup, which is everything an agent needs to call it correctly. Annotations handle the safety profile.
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 100%, so the schema already documents all six parameters including sort_by and include_closed semantics, and the description largely restates them. The one addition beyond the schema is how lowSample results interact with the default ranking, which is marginal against fully-covered parameters.
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?
States a specific verb and resource ('returns where to farm an item on a game server: the stages that drop it') and enumerates the returned fields (runs, quantity, drop rate, sanity per item). This distinguishes it from the sibling get_stage_drops, which goes the opposite direction.
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 routes the agent through search_items to obtain the item ID, and spells out the alternative modes via sort_by=drop_rate and include_closed=true. It never names get_stage_drops as the alternative for stage-first queries, so it stops short of full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns what a stage drops on a game server: each item with runs (times), quantity, drop rate (items per run) and sanity per item, highest rate first, then the items it no longer drops; with the sanity cost of the stage and whether it is open now. Takes the stage ID from search_stages (codes are shared by several stages); a code works too if only one stage on the server has it.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Language of the names in the result: zh, en, ja or ko. Default en. | en |
| server | No | Game server: CN (China), US (global, English), JP (Japan) or KR (Korea). Default CN. | CN |
| stage_id | Yes | Stage ID, from search_stages: main_01-07. A code works too if only one stage on the server has it: 1-7 |
| Name | Required | Description |
|---|---|---|
| note | No | |
| rows | Yes | The items the stage drops, highest rate first; then those of windows that ended (end not null), which it no longer drops, such as the bonus drops of past events |
| stage | Yes | |
| server | Yes | |
| source | Yes | |
| dataAsOf | No | When the drop data was calculated, RFC 3339 in UTC |
| truncated | Yes | Whether items were left out, past 100 |
| definitions | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds real behavioral context the annotations cannot: result ordering (highest rate first), inclusion of items no longer dropped, and the open/closed status of the stage.
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 tightly packed sentences: the first front-loads what comes back and its ordering, the second handles input sourcing. No filler or 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?
With an output schema present and annotations covering safety, the description only needs to add ordering and sourcing semantics, which it does. An agent has everything required to select and invoke it correctly.
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 100% with enums and defaults documented for lang and server, so the schema does the heavy lifting. The description's note about codes being shared across stages largely restates the stage_id schema description ('A code works too if only one stage on the server has it'), so it adds little beyond the baseline.
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 opens with a specific verb and resource ('Returns what a stage drops on a game server') and enumerates the returned fields (runs, quantity, drop rate, sanity cost), which distinguishes it from search_stages and get_item_drop_rates without opening either schema.
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 gives an explicit prerequisite and routing rule: take the stage ID from search_stages, and a bare code only works when unique on the server. It does not state when-not to use it or contrast directly with get_item_drop_rates, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists the events (limited-time activities) of a game server: status now (open, upcoming or closed), open and close times, whether a rerun. By default the open and upcoming events with their stage IDs (for get_stage_drops), or the latest 3 if there are none; open_only=false lists every event, latest first, with stage counts only. The main story and the permanent side stories are not events.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Language of the names in the result: zh, en, ja or ko. Default en. | en |
| limit | No | Most events to return, 1 to 50. Default 20. | |
| server | No | Game server: CN (China), US (global, English), JP (Japan) or KR (Korea). Default CN. | CN |
| open_only | No | true (default): the events open or upcoming on the server, with their stages; if there are none, the latest 3. false: every event of the server, latest first, without their stages. |
| Name | Required | Description |
|---|---|---|
| now | Yes | The time of the statuses, RFC 3339 in UTC |
| note | No | |
| events | Yes | |
| server | Yes | |
| source | Yes | |
| openOnly | Yes | |
| truncated | Yes | Whether limit left out older events |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the bar is lower, and the description still adds real behavior: the two distinct result modes, the fallback to the latest 3 when nothing is open or upcoming, and the loss of stage data under open_only=false. That fallback quirk is exactly the kind of thing an agent could not infer from the schema.
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 the resource definition, then the default behavior, then the mode switch and exclusion — a logical order with no filler. The middle clause is quite densely packed ('status now (open, upcoming or closed), open and close times, whether a rerun'), which costs it a bit of readability.
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 tool with two distinct result shapes, an output schema, and rich annotations, the description covers everything an agent needs to choose a mode and interpret the two result forms. The scope exclusion at the end closes the only remaining ambiguity about whether story content appears here.
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 100%, so baseline is 3, but the description goes beyond restating open_only: it explains the concrete consequence (stage IDs vs stage counts only, ordering) and ties the returned stage IDs to get_stage_drops. lang, limit, and server are left entirely to 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?
States a specific verb (lists) and resource (events), and immediately defines the resource as limited-time activities with status, times, and rerun flag. The closing sentence explicitly excludes main story and permanent side stories, so an agent can distinguish this from search_stages and the drop-rate siblings.
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?
Clear about default behavior (open + upcoming events) and the switch that changes it (open_only=false gives every event, latest first). It also signals that stage IDs returned here feed get_stage_drops, routing the agent forward, and rules out story content. What it lacks is a positive statement of when to prefer this over search_stages/search_items for discovery.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Finds items (materials, battle records, chips, furniture, event items) by name in any language (zh, en, ja, ko), by alias or nickname (土块, 狗粮), by pinyin (guyuanyan) or by item ID, and returns their item IDs (for get_item_drop_rates) and names in every language. Best matches first: exact before prefix before substring, names before aliases. Several items can share an alias (石头 is each tier of Orirock): ambiguous is then true; ask the user which one is meant or decide by context. Items of other types (workshop-crafted materials such as D32 Steel, recruitment tags) are returned only when no listed item matches, with a note saying what they are.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Language of the names in the result: zh, en, ja or ko. Default en. | en |
| limit | No | Most items to return, 1 to 25. Default 10. | |
| query | Yes | Name, alias, pinyin or ID of the item, in any language: 固源岩, Orirock Cube, 石头, guyuanyan or 30012 |
| Name | Required | Description |
|---|---|---|
| note | No | Set when no item of a listed type matched and the results are items of other types: what those are |
| query | Yes | |
| source | Yes | |
| results | Yes | The items found, best match first |
| ambiguous | Yes | Whether several items match as well as the first (an alias of several items, such as 石头 for the four tiers of Orirock): ask which one is meant, or pick by context, rather than take the first |
| truncated | Yes | Whether more items match than the limit |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only cover safety (readOnly, idempotent), but the description discloses real behavior: match ranking (exact > prefix > substring, names > aliases), the ambiguous flag for shared aliases, and the fallback rule where other item types are returned only when nothing else matches, with a note. That is exactly the context an agent needs to interpret results.
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?
A single dense paragraph is front-loaded with the core capability, then ranking, then ambiguity, then fallback. Every sentence carries information, though the item-type enumeration and the alias example could be trimmed slightly without loss.
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 read-only search with a documented output schema and full schema coverage, the description covers input modes, ranking, ambiguity handling and fallback. It omits what happens when limit is hit or how results are ordered when scores tie, which is a minor remaining gap.
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 100%, so baseline is 3; the description still adds value by explaining that query accepts names in any language, aliases, pinyin and IDs (with examples that mirror but extend the schema), and clarifies that lang selects the language of returned names. It does not explain limit behavior or result truncation, so not a 5.
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?
States a specific verb and resource ('Finds items ... by name in any language, by alias, by pinyin or by ID') and enumerates the item categories covered. It also points forward to the sibling get_item_drop_rates, so an agent can place it in the workflow immediately.
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?
Gives concrete usage context: any language, alias/nickname, pinyin or numeric ID all work, and it explains the disambiguation path when 'ambiguous' is true (ask the user or decide by context). It does not explicitly state when to prefer a sibling like search_stages or get_item_drop_rates beyond the parenthetical reference, which keeps it below a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Finds stages by code (1-7, S2-12, YW-4; full-width characters work too), by stage ID (main_01-07), or by the name or ID of their zone (第十章, Under Tides), and returns their stage IDs (for get_stage_drops) with their zone, sanity cost and whether they are open on the server now. Codes are not unique: the standard and tough versions of a stage of the main story share them, as do an event, its rerun and the stages it left open for good. Best matches first (the code before the zone, exact before prefix before substring), then the stages open now, standard before tough, original before permanent before rerun. ambiguous is true when several stages share the best-matching code (not for the stages of a zone found by its name): ask the user which one is meant or decide by context.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Language of the names in the result: zh, en, ja or ko. Default en. | en |
| limit | No | Most stages to return, 1 to 25. Default 10. | |
| query | Yes | Code or ID of the stage, or the name or ID of its zone, in any language: 1-7, S2-12, main_01-07, 第十章 or Under Tides | |
| server | No | Game server: CN (China), US (global, English), JP (Japan) or KR (Korea). Default CN. The stages open there now rank first. | CN |
| Name | Required | Description |
|---|---|---|
| query | Yes | |
| server | Yes | Game server of openNow |
| source | Yes | |
| results | Yes | The stages found, best match first |
| ambiguous | Yes | Whether several stages share the code (or ID) that matched best: the standard and tough versions of a stage, or an event, its rerun and the stage it left open; ask which one is meant, or pick by context, rather than take the first. False when the query matched a zone: its stages are listed. |
| truncated | Yes | Whether more stages match than the limit |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare a safe read-only, idempotent, closed-world operation, so the bar is lower, yet the description still adds real behavior: the sort/ranking algorithm, the semantics of the 'ambiguous' flag and its exception for zone-name matches, and the fact that code collisions are expected rather than errors. This is exactly the kind of context annotations cannot 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?
Dense but every clause carries information—lookup modes, collision caveat, ranking rules, ambiguity handling. It is somewhat long and would benefit from breaking the ranking and ambiguity rules into a clearer structure, but nothing is redundant.
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?
An output schema exists so return values need not be explained, yet the description still signals the key returned fields and their purpose. Combined with the ranking rules and ambiguity handling, an agent has everything needed to call this correctly even for a four-parameter 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 description coverage is 100%, so the baseline is 3; the description adds value by clarifying that 'query' accepts codes, IDs, and zone names in any language with examples (full-width chars, 第十章, Under Tides) and that 'server' affects ranking order. It stops short of explaining 'limit' or 'lang' beyond the schema, so it is not fully additive.
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?
Opens with a specific verb+resource ('Finds stages') and enumerates the three lookup modes (code, stage ID, zone name/ID) with concrete examples. It also names the downstream consumer (get_stage_drops) and the returned fields (stage IDs, zone, sanity cost, open status), making it unmistakable against siblings like get_stage_drops and list_events.
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 the non-uniqueness of codes, the ranking order applied (code before zone, exact/prefix/substring, open-now, standard before tough, original/permanent/rerun), and what to do when 'ambiguous' is true: ask the user or decide by context. It also routes the agent to get_stage_drops for drops, giving clear when-to-use guidance.
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.
get_dataset_infoget_item_drop_ratesget_stage_dropslist_eventssearch_itemssearch_stagesCS2 skin prices, case odds and ROI, Armory value, and Trade Up contracts.
Live data on AI agents, APIs and models: prices, free tiers, limits, outages, real-world usage.
Live CS2 skin prices: BUFF163, YouPin, Skinport, CSFloat, Steam and 8 more markets, Doppler phases
RS3 Grand Exchange prices, item lookup, player hiscores, and RuneScape Wiki content
Add one secure layer between your agents and this server.
