Skip to main content
Glama
random-pokemon-mcp

random-pokemon-mcp

by yuren-dev

calc_damage

Read-only

Calculates simplified single-target Pokémon physical or special damage estimates from stats, move type, power, category, and optional modifiers; use for quick battle calculations, not full simulation.

Instructions

Regular single-target physical/special damage. No new fields: exact 0.2.0 numeric compatibility. Any new field enables Gen IX modifiers and stepwise rounding. useAbilities=true selects each species' first non-hidden ability; attackerAbility/defenderAbility override (auto/none/API identifier). Weather is current state, not inferred from setters. Explicit move type/power required. 仍未计入项:烧伤、反射壁/光墙/极光幕、双打/多目标、特殊招式机制(太晶威力下限/太晶爆发/多段/固定伤害等)、星晶、未列出的特性/道具、场外持续伤害与回血、极端数值溢出;不是完整对战模拟。

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "attacker": "<attacker>",
      "defender": "<defender>",
      "moveType": "<moveType>",
      "power": "<power>",
      "category": "<category>"
    },
    "name": "calc_damage"
  }
}

Input Schema

NameRequiredDescriptionDefault
hpEVNo
hpIVNo
itemNo
levelNo
powerYes
attackNo
defenseNo
terrainNo
weatherNo
attackerYes
categoryYes
criticalNo
defenderYes
moveNameNo
moveTypeYes
priorityNo
teraTypeNo
currentHPNo
useAbilitiesNo
attackerAbilityNo
defenderAbilityNo
attackerGroundedNo
defenderGroundedNo
defenderTeraTypeNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.0

TDQS

A3.8/5.0
Behavior5/5

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

Annotations only declare read-only/non-destructive behavior. The description adds crucial behavioral details: no-new-fields preserves exact 0.2.0 compatibility, while any new field enables Gen IX modifiers and stepwise rounding; it also explains ability selection/overrides and that weather is current state rather than inferred.

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 front-loads purpose and key compatibility behavior in a compact block, and the length is justified by the tool's complexity and the need for an exclusion list. Dense phrasing and mixed English/Chinese slightly reduce readability, but most sentences earn their place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

It covers scope, key behavioral modes, required inputs, and a thorough list of exclusions, which is valuable for a complex damage calculator. However, with no output schema and many undocumented parameters, the definition still leaves gaps about return values and full parameter semantics.

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

Parameters2/5

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

With 24 parameters and 0% schema description coverage, the description explains only a few high-impact parameters: useAbilities, attackerAbility/defenderAbility, weather, and the requirement for explicit move type/power. Many parameters such as level, item, attack/defense EV/IV/stage/nature, terrain, critical, priority, teraType, currentHP, grounded, and moveName receive no added semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening 'Regular single-target physical/special damage' clearly states the computation and scope, and the exclusion sentence reinforces that it is not a full battle simulator. It does not explicitly name or distinguish the sibling tools, so it stops short of 5.

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

Usage Guidelines4/5

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

The description gives clear context and explicit exclusions: burn, screens, doubles/multi-target, special move mechanics, Stellar, unlisted abilities/items, and off-field effects. It also states that explicit move type/power are required, but it does not name alternative tools such as get_type_effectiveness.

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