slang_lookupResolve a Chinese/Japanese/English community nickname (e.g. "鬼皮", "老喷", "Zard") to the actual card(s): official names, set, number, card_id. 中文用户: 把圈内简称(鬼皮/老喷/大月…)解析成具体是哪张卡。Up to 10 cards. Calls record usage and query metadata within POKEKA.
| Name | Required | Description | Default |
|---|---|---|---|
| term | Yes | The nickname / slang term. |
| Name | Required | Description | Default |
|---|---|---|---|
| note | No | ||
| term | No | ||
| cards | No | ||
| card_count | No |
Changes observed during successful MCP inspections.
Output schema / properties / cards / items / properties / characterAdded value: +{
+ "description": "featured Pokémon (EN species name)",
+ "type": "string"
+}Output schema / properties / cards / items / properties / dex_noAdded value: +{
+ "type": "number"
+}Output schema / properties / cards / items / properties / finish_tiersAdded value: +{
+ "type": "string"
+}Output schema / properties / cards / items / properties / gen_codeAdded value: +{
+ "type": "string"
+}Output schema / properties / cards / items / properties / rarityAdded value: +{
+ "description": "bilingual rarity bucket label",
+ "type": "string"
+}Output schema / properties / cards / items / properties / rarity_displayAdded value: +{
+ "additionalProperties": true,
+ "properties": {
+ "cjk": {
+ "description": "JP-style code (SR/RR/…)",
+ "type": "string"
+ },
+ "en": {
+ "description": "official EN star-system name",
+ "type": "string"
+ }
+ },
+ "type": "object"
+}Output schema / properties / cards / items / properties / rarity_tierAdded value: +{
+ "description": "machine rarity tier key (double_rare/ultra_rare/…)",
+ "type": "string"
+}Output schema / properties / cards / items / properties / set_nameAdded value: +{
+ "type": "string"
+}Output schema / properties / cards / items / properties / variantAdded value: +{
+ "description": "variant slot (master_ball/poke_ball/…); absent for normal",
+ "type": "string"
+}Output schema / properties / cards / items / properties / variant_kindAdded value: +{
+ "type": "string"
+}Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false and destructiveHint=false, which the description complements by disclosing that the tool 'Calls record usage and query metadata within POKEKA' – indicating a side effect (usage logging) and a scope (within POKEKA). It also states 'Up to 10 cards' as a result limit. This adds meaningful behavioral context beyond the annotations, though it does not specify behavior on no matches or errors.
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 concise and front-loaded, stating the main purpose first, then providing examples and a bilingual note. It contains no filler and every sentence adds useful information. The inclusion of the Chinese translation is efficient for the target audience without bloating the text.
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 tool with one parameter and an output schema, the description is complete. It explains what the tool returns (official names, set, number, card_id), the maximum number of results (up to 10), and the side effect (usage recording). Since an output schema exists, it doesn't need to detail the return structure. The agent has enough information to 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?
The single parameter 'term' is fully described in the schema (100% coverage), so the baseline is 3. The description adds value by providing examples of valid nicknames (鬼皮, 老喷, Zard) and specifying supported languages (Chinese/Japanese/English). This enriches the semantic understanding of what constitutes a valid term, going beyond the schema's simple 'The nickname / slang term.'
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's purpose: resolving community nicknames to actual cards, listing the output fields (official names, set, number, card_id). It uses a specific verb 'Resolve' and gives concrete examples. This distinguishes it from sibling tools like search_card, which search by official names, and other market tools. The purpose is unambiguous and unique.
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 the user has a nickname or slang term, and the Chinese note reinforces this. However, it does not explicitly state when NOT to use this tool or mention alternatives (e.g., use search_card for official names). The guidance is implied but not explicit, leaving some ambiguity for an agent deciding between tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.