Penguin Statistics

Search items

search_items

Read-onlyIdempotent

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 (get_item_drop_rates takes a name too; search first when unsure which item is meant) 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.

Input Schema

TableJSON Schema

Name	Required	Description
`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 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

Output Schema

TableJSON Schema

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

Schema Changelog

Changes observed during successful MCP inspections.

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

First observedOct 23, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already cover safety (readOnly, idempotent, closed-world), and the description adds real behavior on top: result ranking (exact > prefix > substring, names before aliases), the existence of an 'ambiguous' flag when an alias maps to multiple items, and a documented fallback that surfaces unrelated item types only when nothing matches.

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?

Front-loaded with the verb and lookup keys, and every sentence carries information (ranking, ambiguity, fallback). It is long and densely parenthetical, which slightly hurts scanability, but there is no filler.

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?

An output schema exists, so return shape needn't be spelled out, and the description still supplies the ranking rules, ambiguity handling, and cross-type fallback an agent needs to interpret results. Nothing needed to call it correctly appears to be missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the property descriptions already explain lang, limit (1-25, default 10) and query with concrete examples. The description repeats the multilingual/alias/pinyin matching that the query schema already documents, so it adds little parameter-level meaning beyond the structured fields.

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 (items), enumerates the item categories covered, the four lookup keys (name in any language, alias, pinyin, ID), and what is returned (IDs plus names in every language). It also explicitly separates itself from get_item_drop_rates, which is a named sibling.

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 routing guidance: 'get_item_drop_rates takes a name too; search first when unsure which item is meant.' It also tells the agent what to do on ambiguity ('ask the user which one is meant or decide by context') and explains when out-of-scope item types appear.

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.