castle-clash-mcp

by mmadersbacher

Overview Schema Source Related Servers Discussions Admin

Python

Local

get_talent

Retrieve talent effect and capability tags for a Castle Clash hero by name, using real game data for accurate results.

Instructions

Talent effect and capability tags.

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": {
      "name": "<name>"
    },
    "name": "get_talent"
  }
}

Input Schema

Name	Required	Description	Default
`name`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 5, 2026

TDQS

C2.2/5.0

Behavior2/5

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

No annotations are provided, so the description bears the full behavioral disclosure burden. It only states 'Talent effect and capability tags' and does not explain that this is a read-only lookup, what happens for unknown names, the response format, or any error behavior. It is not misleading, but it is far too thin.

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

Conciseness3/5

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

At five words, the description has no filler and is extremely brief. However, the brevity sacrifices a verb and clear sentence structure, so it reads more like a label fragment than a useful tool description.

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

Completeness2/5

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

For a one-parameter lookup with no annotations and no output schema, this description is too incomplete. An agent cannot confidently determine the return shape, how to supply the name, or how this tool differs from the many similar get_* siblings in the toolset.

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

Parameters1/5

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

Schema coverage is 0%, so the description must compensate for the undocumented 'name' parameter. It never mentions the parameter, its expected format, or what values are valid. The word 'Talent' is the only indirect hint that 'name' refers to a talent name, which is insufficient.

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

Purpose3/5

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

The description identifies the talent resource and mentions 'effect and capability tags,' which gives some specificity beyond the tool name. However, it is a noun fragment rather than a statement like 'retrieves talent data,' and it does not clearly differentiate get_talent from the many sibling get_* tools.

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

Usage Guidelines2/5

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

There is no guidance on when to use this tool versus alternatives like get_hero, get_insignia, get_crest, or get_equipment. The only usage cue is the word 'talent,' but no when-to-use, when-not-to-use, or alternative selection criteria are provided.

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