Penguin Statistics

Search stages

search_stages

Read-onlyIdempotent

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; to find the stages that drop an item, use get_item_drop_rates) 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.

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).
`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 the user plays on: CN (China), US (global, English), JP (Japan) or KR (Korea). Default CN. The stages open there now rank first.	CN

Output Schema

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

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 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)."

changedInput schema / properties / server / description

Previous value: -"Game server: CN (China), US (global, English), JP (Japan) or KR (Korea). Default CN. The stages open there now rank first."New value: +"Game server the user plays on: CN (China), US (global, English), JP (Japan) or KR (Korea). Default CN. The stages open there now rank first."

First observedOct 23, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already cover safety (readOnly, idempotent, non-destructive), yet the description adds substantial behavioral context: codes are not unique across standard/tough, event/rerun/permanent variants, and it spells out the ranking order and the meaning of the ambiguous flag. This is exactly the kind of non-obvious behavior annotations cannot express.

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?

Info is front-loaded with the query forms first and caveats after, and nearly every clause carries decision-relevant content. The single long run-on sentence makes it dense to parse, costing some structure points.

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 4-param search tool with an output schema and full annotations, the description covers everything an agent needs: accepted inputs, ranking, ambiguity handling, uniqueness pitfalls, and server effects. Return-value detail is appropriately delegated to the output schema.

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 baseline is 3, but the description adds real meaning: full-width characters are accepted, the query may be a zone name/ID, and server determines which stages rank first. The lang/limit params are left to the schema, which already documents them adequately.

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 (finds) and resource (stages) and enumerates the accepted query forms — code, stage ID, zone name/ID — with concrete examples. It also distinguishes itself from siblings by naming get_stage_drops and get_item_drop_rates, so an agent can route correctly without opening another schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly names the alternatives and the condition that selects them (for drops of a stage use get_stage_drops; for stages dropping an item use get_item_drop_rates). It further tells the agent what to do on ambiguity: ask the user or decide by context — actionable 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.

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.