Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@pokemon-mcp 陽気マスカーニャの変幻自在トリプルアクセル、無振りガブは耐える?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
正確なポケモンデータと第9世代ダメージ計算を提供する MCP サーバー。 Claude Code が Web 検索の代わりにこれを叩くことで、コンテキスト消費を抑えつつ正確な数値を得る。
ポケモンのデータは大半が構造化(種族値・技威力・タイプ相性)で、数値の正確さが命。 embedding 検索は意味的に近いものを返すため数値を取り違えるリスクがある。よって本プロジェクトは embedding を使わず、exact lookup(SQLite/PokeAPI)+ 計算エンジンで構成する。
Related MCP server: Pokemon Showdown MCP Server
flowchart LR
CC[Claude Code] -- MCP/stdio --> S[server.py FastMCP]
S --> D[damage.py 第9世代計算]
S --> DB[(SQLite)]
DB -. 未取得なら遅延フェッチ .-> API[PokeAPI]
D --> TC[type_chart.py]
D --> NA[natures.py]damage.py — ダメージ式・実数値・多段(トリプルアクセル威力20/40/60)・乱数16通り・KO%(畳み込み)。命中(光の粉等)は別軸。
type_chart.py — 第6世代以降のタイプ相性。
natures.py — 性格補正(日本語名エイリアス対応)。
data.py — SQLite キャッシュ + PokeAPI 遅延フェッチ。
server.py — FastMCP でツール公開。
ツール | 役割 |
| 種族値・タイプ・特性 |
| 威力・命中・タイプ・分類・多段 |
| 相性倍率 |
| 実数値 |
| 撃ごと/累計のダメージ・KO%(多段・テラスSTAB・道具・天候対応) |
| 命中率・多段の命中回数分布(光の粉/ふくがん/ランク補正) |
ポケモン名・技名は英語slug/日本語名どちらも可(日本語名の解決には build_db.py --aliases で索引構築が必要)。
道具(いのちのたま/こだわり系/たつじんのおび/タイプ強化アイテム等)・天候(晴れ/雨/砂/雪)に対応。
uv sync
uv run pytest # ダメージエンジンの検証(今日の手計算を再現)
uv run pokemon-mcp # MCPサーバー(stdio)を起動
# 全件オフラインDBを作る場合(任意・数分):
uv run python scripts/build_db.py# /path/to/pokemon-mcp は clone した実際のパスに置き換える
claude mcp add --scope user pokemon -- uv --directory /path/to/pokemon-mcp run pokemon-mcp登録後はそのまま日本語で聞けば、Claude が裏でツールを呼ぶ(Web検索しないのでコンテキストを食わない):
「陽気マスカーニャの変幻自在トリプルアクセル、無振りガブは耐える?」
「トリプルアクセルが光の粉持ちに3発当たる確率は?」
「いのちのたま+晴れのリザードン かえんほうしゃ、フシギバナへのダメージは?」
calc_damage — 対面ダメージ(撃ごと/累計のレンジ・KO%):
// 入力: 陽気マスカーニャ(変幻自在) A252 トリプルアクセル vs 無振りガブ
{ "attacker": "meowscarada", "defender": "garchomp", "move": "triple-axel",
"attacker_offense_ev": 252, "attacker_nature": "jolly", "protean": true }
// 出力(抜粋)
{ "per_hit": [ {"hit":1,"min":64,"max":84}, {"hit":2,"min":132,"max":156}, {"hit":3,"min":196,"max":232} ],
"cumulative": [ {"after_hit":2,"ko_chance":1.0} ], // 2撃目で確定KO
"defender_hp": 183, "type_eff": 4.0, "stab": 1.5 }道具・天候・テラスの例:
{ "attacker":"charizard", "defender":"venusaur", "move":"flamethrower",
"attacker_offense_ev":252, "attacker_nature":"modest",
"item":"life-orb", "weather":"sun" } // 晴れ×いのちのたま ≒ x1.95calc_accuracy — 命中率・多段の命中回数分布:
{ "move":"triple-axel", "bright_powder": true }
// → per_check_hit_chance 0.81, all_hits_chance 0.531441,
// hit_count_distribution { "0":0.19, "1":0.1539, "2":0.124659, "3":0.531441 }calc_stat — 実数値:
{ "base":110, "level":50, "ev":252, "nature":"jolly", "stat":"atk" } // → 162type_effectiveness — 相性倍率:
{ "attacking_type":"ice", "defending_types":["ground","dragon"] } // → 4.0(こうかばつぐん)get_pokemon / get_move — 素のデータ:
get_pokemon("garchomp") → base_stats / types / abilities
get_move("triple-axel") → power 20, accuracy 90, min_hits/max_hits 3, damage_class physicalcalc_damage のパラメータ早見引数 | 既定 | 説明 |
| (必須) | 名前(英語slug または日本語名) |
| 50 | レベル(1〜100) |
| 0 / 31 / hardy | 攻撃側(物理=A、特殊=Cは技分類から自動) |
| 0 / 0 / 31 / hardy | 防御側 |
| false | 変幻自在/リベロ(常にSTAB 1.5) |
| null | テラスタイプ(元タイプ一致なら2.0。攻撃側STABのみ) |
| null |
|
| null |
|
| false | 急所 |
| 1.0 | その他の手動補正倍率 |
命中(光の粉等)は別軸。
calc_damageは命中前提のダメージ・KO%を返す。命中率はcalc_accuracyを使う。 可変多段(2-5発)のko_chanceはヒット数分布で重み付け、ko_chance_all_hitsは最大ヒット前提(スキルリンク/こだわりサイコロ時)。
技名は取得時に自動で日本語索引へ登録される。ポケモン名を含めて全件を日本語で引くには、一度だけ索引を構築する:
uv run python scripts/build_db.py --aliases # 数分・一度きり
# → 以後「ガブリアス」「かえんほうしゃ」等でも引けるtests/test_damage.py が「陽気マスカーニャ(変幻自在)トリプルアクセル vs 無振りガブリアス Lv50」の
手計算(各撃 64-84 / 132-156 / 196-232、2撃目で確定気絶)を再現することでエンジンを検証している。
補正順序は第5世代以降の公式式(天候 → 急所 → 乱数 → タイプ一致 → 相性)に準拠。
本プロジェクトのソースコードは MIT License で公開している。
これは非公式・非営利のファンプロジェクトです。
Pokémon およびポケモンのキャラクター名・技名は、任天堂 / 株式会社クリーチャーズ / 株式会社ゲームフリーク(The Pokémon Company)の商標です。
本プロジェクトは任天堂・The Pokémon Company とは一切関係なく、公認・後援も受けていません。
ゲームの画像・音声・アートワーク等の著作物は一切含みません。種族値・技・タイプ相性などの
事実データは PokéAPI から実行時に取得するのみで、本リポジトリには
同梱・再配布していません(data/pokedex.db は .gitignore 済み)。
MIT ライセンスは本プロジェクトのコードにのみ適用され、ポケモンのデータ・名称・商標には 及びません。
非営利・個人利用を前提としています。商用利用は権利者の許諾が必要です。
技の命中率を計算。光の粉(x0.9)・ふくがん(x1.3)・命中/回避ランクに対応。
トリプルアクセル/トリプルキックは各撃ごとに独立判定するため、当たった回数の分布と 「全段命中する確率」も返す(例: トリプルアクセル vs 光の粉 = 各撃81%、3発命中 53.1%)。
| Name | Required | Description | Default |
|---|---|---|---|
| move | Yes | ||
| bright_powder | No | ||
| compound_eyes | No | ||
| accuracy_stage | No | ||
| evasion_stage | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses important behaviors: the multiplicative effects of bright powder (x0.9) and compound eyes (x1.3), support for accuracy/evasion rank stages, and for multi-hit moves, the return of hit distribution and all-hit probability. This is comprehensive for a calculation tool.
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 remarkably concise: two sentences with an example. It front-loads the primary purpose and efficiently covers both normal and multi-hit scenarios. Every sentence adds value without 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?
Given 5 parameters, 1 required, and no output schema, the description sufficiently explains the tool's behavior and output for the key use cases (single-hit and multi-hit). It could mention default values or edge cases, but overall it is complete enough for an agent to use 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?
Despite 0% schema description coverage, the description adds meaning by explaining how parameters like bright_powder, compound_eyes, and stages affect the calculation. It also clarifies the special handling for multi-hit moves, which is not obvious from parameter names alone.
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 purpose: 'calculate move accuracy.' It specifies support for items (bright powder, compound eyes), accuracy/evasion stages, and multi-hit moves like triple axel/triple kick. This distinctly differentiates it from sibling tools like calc_damage and calc_stat.
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 provides context on when to use: for accuracy calculations including items and stages. It also mentions handling of multi-hit moves. However, it does not explicitly state when not to use or list alternatives, but the context is clear enough for correct selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
対面のダメージを計算(多段対応)。撃ごと/累計のレンジとKO%を返す。
物理/特殊は技の分類から自動判定(物理=こうげき/ぼうぎょ、特殊=とくこう/とくぼう)。
protean=True で変幻自在/リベロのSTAB。tera_type 指定でテラスタルのSTAB(元タイプ一致なら2.0)。
item: 攻撃側の持ち物(life-orb / choice-band / choice-specs / expert-belt / muscle-band / wise-glasses / charcoal 等のタイプ強化アイテム)。
weather: sun/rain/sand/snow(晴れ/雨/砂/雪。日本語可)。晴れ雨は炎水技、砂雪は岩氷の防御に影響。
攻守のポケモン名・技名は英語slug/日本語名どちらも可(日本語は要 build_db --aliases)。
tera_type は攻撃側のSTABのみに反映(防御側の相性計算には影響しない)。
命中(光の粉等)は別軸。本ツールは命中前提のダメージ・KO%を返す(命中率は calc_accuracy)。 可変多段(2-5発)の ko_chance はヒット数分布で重み付け、ko_chance_all_hits は最大ヒット前提。
| Name | Required | Description | Default |
|---|---|---|---|
| attacker | Yes | ||
| defender | Yes | ||
| move | Yes | ||
| level | No | ||
| attacker_offense_ev | No | ||
| attacker_iv | No | ||
| attacker_nature | No | hardy | |
| defender_hp_ev | No | ||
| defender_defense_ev | No | ||
| defender_iv | No | ||
| defender_nature | No | hardy | |
| protean | No | ||
| tera_type | No | ||
| item | No | ||
| weather | No | ||
| crit | No | ||
| other | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It thoroughly explains auto physical/special classification, protean/tera_type STAB effects, item/weather influences, and the distinction between ko_chance and ko_chance_all_hits for multi-hit moves.
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?
Well-structured with bullet points and front-loaded purpose. Each sentence adds value, but given the complexity (17 params), length is justified. Slightly verbose but efficient overall.
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?
Very comprehensive: covers return values, multi-hit nuances, weather interactions, and prerequisites (aliases). No output schema exists, but description adequately explains what is returned.
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 0%, so description must compensate. It adds meaning to key parameters like item (lists examples), weather (specifies effects), protean, tera_type (only affects attacker STAB), and others, significantly enhancing beyond 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?
The description clearly states it calculates damage in opponent battles supporting multi-hit moves, and returns range per hit/cumulative and KO%. It distinguishes from sibling calc_accuracy by explicitly noting accuracy is separate.
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?
Provides explicit guidance: when to use (damage calculation with various factors), when not (accuracy handled by calc_accuracy), and explains behaviors like multi-hit KO chance weighting and the need for aliases for Japanese names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
実数値を計算。stat は hp/atk/def/spa/spd/spe。nature は英名/日本語名どちらも可。
| Name | Required | Description | Default |
|---|---|---|---|
| base | Yes | ||
| level | No | ||
| iv | No | ||
| ev | No | ||
| nature | No | hardy | |
| stat | No | atk |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the transparency burden. It mentions calculation of real values but does not disclose the return format, behavior under invalid inputs, or whether the calculation is deterministic. A calculation tool requires less transparency, but the lack of any detail on output or constraints is a gap.
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 two sentences, immediately states the purpose, and provides key parameter hints without any fluff. It is optimally concise.
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?
Given the tool has 6 parameters and no output schema or annotations, the description is incomplete. It does not explain the calculation formula, the meaning of base/level/iv/ev, or what value is returned. A more complete description would detail the calculation or at least the return type.
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?
With 0% schema description coverage, the description must add meaning for all 6 parameters. It only clarifies two (stat and nature), leaving base, level, iv, and ev unexplained. The defaults are present in the schema but no semantics are added beyond that.
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 it calculates real values for a given stat, listing valid stat names (hp/atk/def/spa/spd/spe) and noting that nature accepts English or Japanese names. However, it does not explicitly differentiate from sibling tools like calc_accuracy or calc_damage, leaving some ambiguity.
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 provides no guidance on when to use this tool versus alternatives (calc_accuracy, calc_damage). It only lists valid parameter values, which is helpful but insufficient for choosing among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
特性の効果テキストを返す(例: protean)。
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description does not disclose any behavioral traits such as error handling (e.g., unknown ability), rate limits, or required authentication. It only states what is returned.
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 very short (one sentence and an example). It is concise but lacks structure; key information is not front-loaded.
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 lookup tool with one parameter and no output schema, the description is minimally functional but lacks details like return format or behavior for unknown abilities, reducing completeness.
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 0%, so the description must compensate. It mentions the parameter indirectly via the example 'protean' but does not explain the 'name' parameter's meaning, format, or constraints.
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 it returns the effect text of an ability, with an example ('protean'). This indicates the verb 'get' and resource 'ability effect text', though it could be more precise about the exact output.
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?
No guidance on when to use this tool versus siblings like get_move or get_item. It does not specify context or prerequisites for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
持ち物の効果テキストを返す(例: bright-powder)。
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It states the tool returns text, implying a read-only operation, but does not disclose any potential limitations or side effects. The statement is adequate but minimal.
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 extremely concise, consisting of a single sentence with an example. Every word contributes, and it is front-loaded with the core action.
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?
Given the low complexity (1 param, no output schema), the description is adequate but lacks information about the return format. It states 'returns effect text' but does not specify whether it is a string, object, etc.
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 0%, so the description must compensate. It only provides an example 'bright-powder' but does not explain valid values, format, or case sensitivity. This is insufficient for the sole required parameter.
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 returns the effect text of an item, with an example 'bright-powder'. This differentiates it from sibling tools like get_ability, get_move, and get_pokemon.
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 for retrieving item effects but provides no explicit when-to-use or when-not-to-use guidance. Given similar sibling tools, some context on when to choose this tool would be helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
技の威力・命中・タイプ・分類(物理/特殊)・多段ヒット情報を返す(例: triple-axel)。
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and description only states what is returned. It does not disclose side effects, read-only nature, or any constraints beyond the basic lookup.
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?
Single, well-structured sentence that front-loads the main function. No wasted words.
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?
Given no output schema, the description adequately lists returned fields. However, it lacks any usage context or edge cases, but is sufficient for a simple lookup 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?
The single parameter 'name' is not described explicitly; schema coverage is 0%. The description implies it's the move name via example but adds little beyond the parameter name itself.
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 returns move attributes (power, accuracy, type, category, multi-hit info) with an example. It distinguishes from sibling tools like get_ability or get_pokemon.
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?
No guidance on when to use this tool versus alternatives like calc_damage or type_effectiveness. The description only lists output, leaving usage context implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ポケモンの種族値・タイプ・特性を返す(例: garchomp, meowscarada)。
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations present; description only states output type but lacks details on safety, permissions, error handling, or case sensitivity of the name parameter.
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?
Single sentence with example, no wasted words. Highly concise.
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 lookup tool with one param, description covers output basics but lacks return format or additional behavioral context. With no output schema, more detail would help.
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?
Only parameter 'name' has no schema description; example values (garchomp, meowscarada) provide some context but no format constraints or allowed values.
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 it returns Pokemon's base stats, type, and abilities, using a specific verb and resource. It distinguishes from sibling tools like calc_accuracy which perform calculations.
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?
No explicit when or when-not to use, or alternatives. The purpose is implied but no guidance relative to siblings like get_ability or get_item.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
攻撃タイプ x 防御タイプ(複合可)の相性倍率。例: ice vs [ground, dragon] = 4.0
| Name | Required | Description | Default |
|---|---|---|---|
| attacking_type | Yes | ||
| defending_types | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose all behavioral traits. It states the basic calculation and handles dual types (as shown in example) but does not mention immunity, ability interactions, or return format. Adequate but not comprehensive.
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 a single sentence plus an example, with no unnecessary words. It is front-loaded and efficient, earning its place.
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 no output schema or annotations, the description is insufficient. It does not specify the return value type or structure, nor address edge cases like immunities or invalid types. The Japanese language may also limit broader understanding.
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 0%, so the description must compensate. The example clarifies that defending_types is an array. However, it does not explain allowed values, case sensitivity, or type name formats, leaving ambiguity.
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 it calculates attack type vs defense type effectiveness multiplier, with an explicit example ('ice vs [ground, dragon] = 4.0'). It distinguishes from sibling tools like calc_accuracy and calc_damage by specifying the unique function of type matchup calculation.
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 for looking up type effectiveness but does not provide explicit guidance on when to use this tool vs alternatives (e.g., calc_damage). No exclusions or when-not-to-use conditions are given.
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.
v0.1.0calc_accuracycalc_damagecalc_statget_abilityget_itemget_moveget_pokemontype_effectivenessScored across 8 tools
Each tool has a unique, clearly defined purpose: accuracy calculation, damage calculation, stat calculation, and information retrieval for abilities, items, moves, Pokémon, and type effectiveness. No overlap in functionality.
All tool names follow a consistent snake_case verb_noun pattern: calc_ for calculations, get_ for data retrieval, and type_effectiveness. This makes the set predictable and easy to navigate.
With 8 tools, the server is well-scoped for Pokémon battle simulation and reference. Each tool provides essential functionality without redundancy or bloat.
The tool set covers core battle calculations (damage, accuracy, stats) and key data lookups (Pokémon, moves, abilities, items, type effectiveness). Minor gaps exist, such as no move search by type or ability list, but these are non-critical.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Provide detailed Pokémon data and information through a standardized MCP interface. Enable LLMs an…
Look up Pokemon TCG Pocket cards, sets, packs, and evaluate decks with battle simulations.
Real sold prices, history & PSA population for graded Pokémon cards (EN/JP/CN). Knows nicknames.
Look up Pokémon, moves, abilities, items, natures, and type matchups from PokéAPI v2.