Penguin Statistics

Item drop rates

get_item_drop_rates

Read-onlyIdempotent

Where to farm an item: ranks every stage of a game server that drops it, with sanity per item, drop rate (items per run), runs (times) and quantity. Use it for any question about where to get an item, its best or most efficient stage, or which of several stages to run for it: one call ranks every stage, so don't look stages up one by one with get_stage_drops (only a named stage left out of the top_n returned). 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. item_id takes the item's name in any language; search_items first only when the name may mean several items.

Input Schema

Name	Required	Description	Default
`lang`	No	Language of the names in the result: the language the user writes in, zh, en, ja or ko (en for other languages, and if omitted).
`top_n`	No	Most stages to return, 1 to 100. Default 10.
`server`	Yes	Game server the user plays on: CN (mainland China: 国服, 官服, B服), US (global, English: 国际服, 美服), JP (日服) or KR (韩服). Stages, events and drop rates differ by server. Use the server the user named or the conversation makes clear; a user writing Chinese, Japanese or Korean most likely plays CN, JP or KR. If you can't tell, ask the user which server they play on before calling. Name the server in your answer.
`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.

Output Schema

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

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedOct 23, 2026

removedInput schema / properties / lang / default
```
Removed value: -"en"
```

changedInput schema / properties / lang / description

Previous value: -"Language of the names in the result: zh, en, ja or ko. Default en."New value: +"Language of the names in the result: the language the user writes in, zh, en, ja or ko (en for other languages, and if omitted)."

removedInput schema / properties / server / default
```
Removed value: -"CN"
```

changedInput schema / properties / server / description

Previous value: -"Game server: CN (China), US (global, English), JP (Japan) or KR (Korea). Default CN."New value: +"Game server the user plays on: CN (mainland China: 国服, 官服, B服), US (global, English: 国际服, 美服), JP (日服) or KR (韩服). Stages, events and drop rates differ by server. Use the server the user named or the conversation makes clear; a user writing Chinese, Japanese or Korean most likely plays CN, JP or KR. If you can't tell, ask the user which server they play on before calling. Name the server in your answer."

changedInput schema / required

Previous value: -[
-  "item_id"
-]New value: +[
+  "item_id",
+  "server"
+]

First observedOct 23, 2026

TDQS

A4.8/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Although annotations already declare it read-only and idempotent, the description adds substantial behavioral context beyond them: default ranking excludes closed stages, low-sample stages rank after others, gachas and recruitment rank last, sort_by switches the ranking, and include_closed=true expands to past events and ended drops.

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 front-loaded with purpose, then usage, then ranking behavior. It is dense but every sentence contributes—there is no filler or repetition of annotation metadata—though the single long paragraph packs several constraints together, which slightly reduces scannability.

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?

For a six-parameter read-only tool with a full schema and an output schema, the description covers everything an agent needs to call it correctly: purpose, alternatives, default sorting, sample-size handling, closed-stage inclusion, item-name ambiguity, and server/language expectations. Return values are not described, which is appropriate since an output schema exists.

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 coverage is 100%, so the schema already documents all parameters. The description still adds useful semantics: item_id accepts names in any language and search_items is only needed when the name may be ambiguous; it also clarifies that include_closed adds past events and ended drops, and that sort_by changes ranking direction. The server/language details are largely already in the schema, keeping this from a 5.

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?

States a specific verb and resource: 'ranks every stage of a game server that drops it', and lists the ranking fields (sanity per item, drop rate, runs, quantity). It explicitly distinguishes itself from sibling get_stage_drops, so an agent can identify it without opening schemas.

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?

Gives explicit when-to-use: 'any question about where to get an item, its best or most efficient stage, or which of several stages to run'. It also names the alternative and when not to use it ('don't look stages up one by one with get_stage_drops') and when to precede with search_items.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Penguin Statistics tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.