castle-clash-mcp

Overview Schema Source Related Servers Discussions Admin

skill_damage

Compute exact skill damage for any ATK value using the verified damage formula. Specify skill and optional level to get per-hit damage and target count.

Instructions

Exact skill damage for a given ATK, using the verified skill primitive (ceil(damage% * ATK / 100), from docs/GAME_MATH.md). Defaults to the skill's max level. Returns per-hit damage and the target count.

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": {
      "skill": "<skill>",
      "atk": "<atk>"
    },
    "name": "skill_damage"
  }
}

Input Schema

Name	Required	Description	Default
`atk`	Yes
`skill`	Yes
`skill_level`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 5, 2026

TDQS

A4.1/5.0

Behavior4/5

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

With no annotations provided, the description carries the full transparency burden. It discloses the exact formula, the default skill level behavior, and what the tool returns. It does not cover error cases or invalid inputs, but for a pure calculation tool the disclosed information is strong.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two dense sentences with no filler. The formula is front-loaded, the default behavior is stated, and the return content is summarized, making every sentence earn its 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?

The formula and return semantics are covered, but the tool has no output schema and no annotations, so the description must also explain the call contract fully. The unresolved skill parameter format and lack of explicit output structure leave an agent with some ambiguity when invoking the tool.

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 description coverage is 0%, so the description must compensate. It gives meaning to atk through the formula and explains skill_level's default, but it does not clarify what the skill string should be (e.g., skill ID vs. name) or where valid skill values come from. This is a notable gap because skill is a required parameter.

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?

The description states a clear, specific purpose: computing exact skill damage from ATK using a given formula. It distinguishes this calculation tool from data-retrieval siblings like skill_data, skill_levels, and hero_skills by focusing on the derived damage value and return values.

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 phrase 'for a given ATK' clearly indicates when to use the tool, and the note about defaulting to max level explains how the optional skill_level parameter behaves. It does not explicitly name alternatives or exclusion conditions, but the usage context is clear enough for an agent to select it.

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