castle-clash-mcp

by mmadersbacher

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation2/5
There are several overlapping clusters: get_hero/hero_complete/hero_sheet/hero_dossier all claim to return the full hero record, and the get_insignia/get_crest/get_rune/get_enchantment/get_equipment group is hard to differentiate at a glance. Descriptions carry nuances, but with 47 tools an agent is likely to pick the wrong one.
Naming Consistency3/5
Most tools use snake_case verb_noun forms (list_heroes, get_hero, search_game_data), but many are noun-phrase or bare names (hero_stats_calc, tier_list, related, gacha_odds), and similar operations get inconsistent names (get_game_table vs system_lookup vs get_system). The naming is readable but does not reliably signal each tool's role.
Tool Count2/5
47 tools is well beyond the practical upper bound and is padded with near-duplicates that could be merged into parameterized endpoints (hero record, item lookup, search). A broad game-data domain can justify many tools, but this count creates maintenance and selection overhead.
Completeness4/5
The surface is unusually complete: heroes, skills, items, gacha, game tables, build recommendation/validation, and combat math are all covered, with search/refresh paths to avoid dead ends. Minor workarounds remain (no direct list_skills/list_items, and simulate_fight omits skills/energy), but agents can still accomplish the core workflows.
Average 3.5/5 across 47 of 47 tools scored. Lowest: 2.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 9 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It adds one useful detail (English-annotated via name_en) but does not mention return format, pagination/limit behavior, error cases, or any side effects. This is a minimal disclosure for a data-fetching tool.
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?
The description is very short and contains no filler, but it is a cryptic fragment rather than a clear, front-loaded definition. It earns its place as a hint but is too terse to be considered well-structured guidance.
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?
Given no annotations, no output schema, and sparse parameter docs, the description should compensate by explaining the system identifier, the meaning of rows, and the limit parameter. The sibling context includes several similar get_* tools, and this description does not clarify how get_system fits among them.
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 description coverage is 0%, so the description must explain what the system and limit parameters mean. It does not address either parameter; 'English-annotated (name_en)' hints at an output field but not how to fill in the required system argument.
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 resource ('game system') and a concrete verb ('get'), but 'Rows of a game system' is vague about what is actually returned. It points to game_systems for context but does not clearly distinguish this from sibling tools like game_systems or system_lookup.
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?
The only usage guidance is 'see game_systems,' which hints at a relationship but provides no explicit when-to-use or when-not-to-use instructions. No alternatives are named, and the tool's role relative to similar sibling tools is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, but it only states that the tool returns a single catalog entry with effect/stats where casclash provides them. It does not disclose what happens when no entry is found, whether the result is a full object or a summary, pagination, or any other behavioral trait.
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 is a single, front-loaded sentence with no filler. It is compact, though the parenthetical is slightly cryptic and could be clearer without much added length.
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 simple two-parameter tool with no output schema and no annotations, the description is too thin. It does not explain what categories exist, what the returned entry looks like, or how this relates to the catalog system referenced by sibling tools like list_catalog and list_categories.
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 description coverage is 0% and the description does not add any meaning to the two required parameters, 'category' and 'name'. The agent is left to guess valid category values or name formats.
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 description names a specific verb and resource ('Get one catalog entry') and adds a qualifier about effect/stats from casclash, which helps distinguish it from broader listing tools. It is not a tautology, though it could be more explicit about what a 'catalog entry' contains.
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?
No when-to-use or when-not-to-use guidance is provided. There are many sibling getter and search tools, but the description does not explain why an agent should choose get_catalog_entry over list_catalog, get_game_table, or search_game_data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It does disclose the output categories and implies a read-only aggregation behavior, but it relies on the vague word 'EVERYTHING' and does not mention limitations, response shape, or what is omitted.
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 is short and front-loaded with the main value proposition. The trailing 'one-stop hero overview' is somewhat redundant with the first sentence, but the overall structure is efficient and easy to scan.
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 tool with no output schema and one undocumented parameter, the description provides enough to choose the tool but not enough to invoke it confidently. It also does not disambiguate against several apparently overlapping sibling tools, leaving significant context missing.
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?
With schema description coverage at 0%, the description needed to clarify the hero parameter's accepted format or values. It merely restates that the call concerns 'a hero,' adding no meaning beyond the property name and type already in the schema.
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 description clearly identifies the tool as a one-call hero overview and itemizes the returned content: complete stats, main skill, totem skill summary, tier, and a recommended build. It does not explicitly contrast itself with siblings, but the aggregate composition makes the purpose obvious.
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?
The phrase 'one-stop hero overview' implies use when a broad hero summary is needed, but it gives no explicit when-to-use versus alternatives. With siblings like get_hero, hero_complete, hero_dossier, and recommend_build, the agent is left to infer routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It partially meets this by describing the output composition and data sources, but it does not clarify side effects, error behavior, or what the 'pointer' actually looks like in the response.
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 is compact and front-loaded with the core purpose. The parentheticals make it slightly awkward, but there is no wasted content.
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 tool with no output schema and no annotation support, the description is incomplete. It names some return components but omits acceptable hero values, the precise shape of the returned data, and how the 'pointer' is encoded or used.
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?
The schema has only a 'hero' property with no description, and schema description coverage is 0%. The description does not explain the accepted format, naming conventions, or examples for the hero parameter, leaving the agent to guess.
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 description clearly identifies that the tool returns a hero's skills, specifically naming the totem skill (name and level count) and a pointer to the main active skill. It is not a tautology and gives concrete content details, though it does not explicitly distinguish itself from nearby siblings like totem_skill or skill_levels.
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. The mention of get_hero / hero_level_stats is an implementation hint rather than usage direction, and no exclusions or preferred conditions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only lists the data content and source table. It does not explicitly say that it returns a single item by name, how name matching works, or what happens on no match.
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 is a compact, front-loaded fragment with no wasted words. It packs item type, source table, item count, and content fields into one line, though it lacks a verb and reads more as a label than a full tool description.
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?
For a simple single-parameter lookup tool, the description conveys the core domain and return content adequately. However, with no output schema or annotations, it leaves gaps around exact lookup semantics and sibling-tool differentiation, especially given the existence of get_crest and get_equipment.
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?
The schema defines a single required 'name' string with 0% description coverage, so the description must compensate. It does not explain the expected name format, whether it must be exact, or how to reference a specific insignia.
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 description identifies the resource precisely—'Insignia/crest-item (Equipment table, 208 items)'—and names its key contents: per-level Hp/Attack and effect text. It is specific enough to distinguish from many siblings, though it does not explicitly differentiate from get_crest or get_equipment.
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 about when to use this tool instead of alternatives like get_crest or get_equipment. The description implies it is for insignia/crest items, but it gives no exclusions, prerequisites, or selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden, and it does disclose the data content: per-level HP/Attack plus an effect. It does not mention return shape, matching behavior, or edge cases, so transparency is partial.
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?
The description is compact and front-loaded with the resource name, and there is no filler text. However, it is cryptic and saves space at the cost of clarity, so it is only adequately concise.
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 tool with no output schema and no annotations, the description should explain both input and output more fully. It gives a hint about the returned fields but omits how the name parameter works, what a successful result looks like, and what happens for unknown names.
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?
The schema has one required 'name' parameter with 0% description coverage, and the description never clarifies that 'name' is the rune's name or what values are accepted. The reference to '101' could be mistaken as a parameter, adding ambiguity.
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 description identifies the resource ('Rune') and table ('Runes table, 101') and, combined with the tool name get_rune, makes the operation clear. It is distinct from sibling getters like get_talent or get_hero, though it lacks an explicit verb in the description itself.
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 call get_rune versus alternatives such as get_talent or search_game_data. The description implies this is for rune data but does not state exclusions or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of explaining behavior. It only says the result is 'ranked,' without describing ordering direction, output format, default behavior, or how the limit parameter affects results. This is minimal but not misleading.
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 is a single front-loaded sentence with no filler and includes the key scope upfront. It is appropriately concise, though it could trade a little brevity for more behavioral detail.
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 tool is simple with two optional parameters and no output schema, so the description is close to adequate for basic invocation. However, because there are no annotations and no output schema, the missing details about limit behavior and result format leave the description only minimally complete.
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?
Schema description coverage is 0%, so the description must compensate for both parameters. It adds meaning for 'mode' by listing the allowed values, but it says nothing about 'limit' or its behavior. One of the two parameters remains undocumented beyond the raw schema field.
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 description clearly states that the tool returns a ranked tier list and enumerates the valid modes, which gives a specific resource and scope. It does not explicitly contrast itself with sibling tools like rank_heroes or list_heroes, so it misses full differentiation.
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?
The description implies when to use the tool (when you need a tier list for one of the listed modes) but provides no guidance on when not to use it or which sibling tools are better alternatives. No exclusions or comparisons are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden itself. It does reveal that results are per-level stats and lists the stat categories, which is useful behavioral context. However, it does not state the output shape, error behavior, whether it is read-only, or whether data is computed dynamically, so transparency is only partial.
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 is a single compact sentence that front-loads the resource and then lists the included stats. It is reasonably efficient, though the shorthand and lack of sentences explaining input/output reduce clarity slightly.
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?
Given there is no output schema, the description should explain what a caller receives, but it only lists stat names without structure, units, level range, or an example. It also does not clarify the 'name' parameter enough for confident invocation. For a simple one-parameter tool this is borderline, but the missing input semantics and return format make it incomplete.
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?
Schema coverage is 0%, and the only parameter is a generic 'name' with no description. The tool description implies name refers to a crest, but it never explicitly states that 'name' is the crest name, what accepted values look like, or whether the listed camps are valid inputs. This leaves the agent to infer the parameter's meaning.
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 description identifies the resource ('career crest') and enumerates the returned data fields (Attack/HP/Tenacity/Crit/Dodge/Hit_DMG per level), making the tool's purpose clear. It does not explicitly use a verb like 'gets' or 'returns', and it does not contrast with sibling tools, but the resource and content are specific enough to distinguish it from get_talent/get_rune/get_equipment.
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?
No guidance is given about when to use get_crest versus alternatives such as get_talent, get_insignia, or get_equipment. The only implied context is 'career crest', and there is no indication of prerequisites, exclusions, or fallback tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It explains that the tool returns the level's effect text, optional might/cooldown, and the full range, which is useful for a read-only lookup. However, terms like 'full range' are ambiguous, and there is no mention of output format, failure behavior, or input constraints.
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 is very short and front-loaded, with two sentences that each serve a purpose. It could be slightly more explicit about the level parameter format, but it is efficiently structured with no filler.
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?
For a simple lookup tool with three string parameters and no output schema, the description gives enough to understand the core operation and return value. It is incomplete, though: 'full range' is ambiguous, and name/level parameter expectations are missing.
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?
Schema description coverage is 0%, so the description must compensate. It only clarifies the 'kind' parameter by specifying kind='talent' or 'hero', while 'name' and 'level' remain semantically undocumented, including expected formats or valid values.
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 description clearly states that the tool returns the effect text of a talent or hero skill at a specific level, plus might/cooldown when present. It distinguishes itself from sibling tools like get_talent or hero_skills by focusing on per-level effect text, though it does not name those alternatives explicitly.
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?
The description implies usage for looking up a talent or hero skill effect at a given level, but it gives no explicit guidance about when to prefer this tool over similar siblings such as skill_levels, hero_skills, get_talent, or skill_data. No alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full burden of behavioral disclosure. It does this well by revealing that the engine fills remaining slots, avoids anti-synergies with specific examples, and explains every pick. This goes beyond the schema. It could mention error handling or conflicting constraints, but the disclosed behavior is substantive.
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 is compact and front-loaded, with the primary action in the first sentence. The parenthetical examples add useful specificity without fluff. It is slightly dense as a single long sentence, but every clause contributes information.
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?
Given no annotations and no output schema, the description is not fully sufficient. It omits the meaning of `mode`, does not clarify the output structure beyond 'explains every pick,' and does not differentiate the tool from closely related siblings. An agent could call it with just a hero, but the surrounding decision-making and input semantics are incomplete.
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?
Schema description coverage is 0%, so the description must compensate. It adds meaning for the five build-slot parameters by framing them as optional fixed slots and giving an example. However, it says nothing about the required `hero` parameter and leaves `mode` completely unexplained, which is a significant gap for a tool with 7 parameters.
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 description clearly states a specific verb and resource: 'Recommend a full 5-slot build' and enumerates the slots (talent, crest, insignia, enchantment, pet). It also conveys the core behavior of filling unspecified slots. It does not explicitly distinguish itself from the sibling generate_build, which keeps it from a 5.
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?
The description gives a concrete usage mechanism: 'Pass any slot to fix it... the engine fills the rest.' However, it provides no guidance on when to prefer this tool over siblings like generate_build, check_build, or build_score, and states no exclusion criteria. An agent must infer when this tool is the right choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It does reveal that the output consists of per-level English descriptions and references the data source (totem_skills_full), but it does not clarify expected return format, read-only nature, or behavior for missing or invalid hero values.
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 is a single, front-loaded sentence with no filler or repetition. It is concise, though it sacrifices some useful detail about the hero parameter and expected behavior.
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?
With one required parameter, no output schema, and no annotations, the description needs to tell the agent how to invoke the tool correctly and what to expect in return. It only states the resource and that descriptions are per-level in English; it lacks input format guidance, output structure hints, and any connection to sibling tools.
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?
The schema provides no description for the hero parameter (0% coverage), and the tool description only mentions 'hero' implicitly through 'A hero's.' It does not specify whether hero should be a name, ID, or slug, nor does it provide examples or accepted formats. The description fails to compensate for the schema's lack of parameter documentation.
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 description identifies the resource ('a hero's Totem skill') and adds a useful detail ('English description per level'), which helps distinguish it from generic skill-related siblings like skill_data or skill_damage. However, it lacks an explicit verb like 'get' or 'retrieve,' so the action is only implied.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for retrieving a hero's Totem skill, but it gives no explicit when-to-use guidance and does not contrast it with alternatives such as get_talent, get_crest, or skill_data. There is no exclusion or routing information, so an agent must infer the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It does add context by stating that data is per-level and comes from static game data, implying a read-only lookup. However, it does not disclose matching behavior, exact return contents, or failure behavior when a name is not found.
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 is one compact sentence with useful examples and no filler. The colon-separated structure is slightly compressed, but it is front-loaded with the key definition and stays efficient.
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?
For a one-parameter lookup, the description conveys the core purpose: get per-level enchantment data from game data. However, with no output schema and no annotations, it leaves the exact return shape and lookup mechanics under-specified, so an agent would be partly guessing about the response structure.
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?
The schema provides zero description for the 'name' parameter, so the description must compensate. It supplies concrete example values ('Bold Ambition', 'Forest Ward') and clarifies that the names are Soul-Arms skills, which gives useful semantic grounding. It still does not explicitly state that the parameter must be an enchantment name or specify case sensitivity and formatting.
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 description identifies the resource ('Enchantment = Soul-Arms skill') and the data shape ('per-level from game data'), so an agent can tell this is a lookup for enchantment skill data. It stops short of an explicit active verb like 'retrieves', making it slightly less direct than the 5 bar.
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 such as get_soularm, get_talent, or search_game_data. The description defines what an enchantment is, but it never states exclusivity, exclusions, or selection criteria relative to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of explaining behavior. It discloses the source table and the type of content returned (per-level HP/Attack plus effect text), which is useful. However, it does not state whether a single record is returned, how missing names are handled, or whether this is strictly read-only.
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 is a single, dense sentence with no wasted words. It front-loads the resource type and key content details. It could be slightly more structured to separate behavior from parameter guidance, but it remains concise and scannable.
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?
For a simple one-parameter getter, the description gives the core return contents and source table, but with no output schema and no annotations, an agent is left without explicit guidance on output format, valid name values, or how this relates to other equipment/search tools. It is adequate but not complete.
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?
Schema description coverage is 0%, so the description must compensate for explaining the 'name' parameter. It does not explicitly state that 'name' should be an equipment identifier or provide format/casing guidance. The connection is inferable from the tool name and resource type, but the description adds little beyond the schema's existing 'Name' title.
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 description clearly identifies the tool as retrieving an equipment item from the Equipment table and specifies the relevant data fields (per-level HP/Attack and effect text). This distinguishes it from sibling lookups like get_hero, get_talent, or get_rune, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: call this tool when you need equipment data such as per-level stats or effect text. However, there is no explicit guidance about when not to use it or which alternative tools might be preferable, such as get_game_table, get_catalog_entry, or search_all.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden, and it does disclose key behaviors: exact formulas recovered from libgame.so, the attack/armor type mapping, skill_coeff handling, raw Hero.data ratings, and the fact that crit ratings convert to crit chance/damage in the output. It does not mention output structure or edge cases, but the main computation and return content are transparent.
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 is compact and front-loads the core purpose before moving into parameter and return-value details. It is dense but not bloated; a slightly more structured parameter rundown would make it cleaner.
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?
The tool has nine parameters, no output schema, and no annotations, so the description needs to cover more ground. It gives the essential formula context and references docs, but missing semantics for several parameters and the return shape leave the agent guessing for valid calls.
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?
Schema description coverage is 0%, so the description must explain the nine parameters. It does explain attack_type/armor_type values, skill_coeff, and the crit ratings, but leaves atk, is_crit, target_reduce_rating, and target_tenacity_rating undocumented.
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 description opens with a specific verb and resource ('Explain one hit using the engine's exact formulas'), making the tool's job clear. It does not explicitly compare itself to siblings like simulate_fight or combat_effects, though 'one hit' and 'exact formulas' imply that boundary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for exactly computing a single hit's damage rather than simulating a whole fight, and it points to docs/GAME_MATH.md for the formula source. It gives no explicit when-to-use or when-not-to-use guidance against sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It conveys that stats are computed and shown side-by-side, but it does not disclose the kind of stats returned, whether the operation is read-only, error behavior, or any output format details.
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 is a single front-loaded sentence with no filler. It is concise and scannable, though slightly more detail about computed stats or output could improve value without sacrificing structure.
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?
With no annotations, no output schema, and 0% schema description coverage, the description is too sparse to fully support correct invocation. An agent is left uncertain about what stats are computed, what the response looks like, and what edge cases exist for invalid or missing heroes.
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 does add meaning by indicating hero_a and hero_b are the two heroes and that stars/level are shared across both, which clarifies parameter relationships. However, it does not explain parameter ranges, defaults, or expected hero name formats.
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 uses a specific verb-plus-resource structure: side-by-side computed stats for two heroes. The 'two heroes at the same stars/level' phrasing clearly differentiates this from single-hero stat tools like get_hero or hero_stats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used when comparing two heroes under identical stars/level conditions. However, it does not explicitly state when not to use it or name alternative tools such as rank_heroes or hero_dossier.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states what data is covered but does not mention output format, whether entries are sorted, whether zero-count systems are included, or any other operational behavior. This is a minimal statement of content, not of behavior.
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 is a single focused sentence, starting with the core purpose and then enumerating examples. The parenthetical list is long but informative and not redundant. It is efficient and well-structured, though the list could arguably be trimmed without losing meaning.
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?
For a zero-parameter tool, this is minimally adequate: it tells the agent what the tool provides (system names and counts). However, with no output schema, the description does not specify the response structure (e.g., JSON object, array), which leaves some uncertainty about how the result will be consumed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline of 4 applies. The description adds useful context about what the returned entity set covers, though parameter-specific explanation is moot.
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 description clearly identifies the resource (Castle Clash data systems) and the key information returned (entry counts), and the parenthetical list of systems gives concrete grounding. It distinguishes itself from sibling tools like list_heroes or get_hero by being a high-level catalog overview, though it lacks an explicit verb like 'return' or 'list'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied rather than stated: a user would call this to see the full scope of game systems and their counts, not to get details on a single system. No explicit guidance is given about when not to use it or which sibling tool to use instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It does disclose a useful behavior: rows carry English *_en fields. But it does not mention the limit behavior, how many rows are returned, whether rows are returned in any order, or what happens when the table name is invalid. This is acceptable for a simple read tool but not fully transparent.
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?
Two short sentences convey the core purpose, the source of valid table names, and a key output convention. There is no filler or repetition, and the most important information is front-loaded.
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?
For a simple lookup tool, the description covers the core purpose and output convention, and references list_game_tables for valid names. However, with no annotations, no output schema, and no parameter descriptions, the missing limit semantics and lack of explicit return-shape guidance leave a moderate gap. It is usable, but an agent would still need to infer or discover important invocation details.
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?
Schema description coverage is 0%, so the description must compensate for both parameters. The phrase 'by name (see list_game_tables)' gives partial meaning for the table parameter, but the limit parameter is completely unexplained in both the schema and the description. The description adds some value but leaves a required part of the invocation semantics undocumented.
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 description states the operation (fetch rows), the resource (a game data table), and how the table is identified (by name). It also points to list_game_tables as the source for valid names, which helps distinguish this generic row-fetcher from the sibling-specific getters like get_hero or get_talent. It is not a full 5 because it does not explicitly contrast itself with search_game_data or other data-retrieval siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The parenthetical '(see list_game_tables)' gives implied usage guidance: call list_game_tables first to discover valid table names. However, it does not explicitly state when to use this tool instead of search_game_data, list_game_tables, or the individual entity getters, nor does it give exclusions or alternative conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does add useful semantic context beyond the name: the values are 'flat' additive bonuses (not scaling multipliers) and represent 'base stats' rather than modified totals. However, it does not disclose whether the operation is read-only, what happens for an out-of-range or invalid level, or what the response contains.
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?
A single 15-word sentence with the core subject front-loaded ('Soul-Arms base stats') and a clarifying parenthetical appended. Every word earns its place; there is no filler, restated schema, or redundant phrasing.
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?
For a simple single-parameter lookup with no annotations, no output schema, and no parameter descriptions, the description covers the essential invocation context: what is returned (flat Attack/HP/Tenacity) and what the input means (a level). The remaining gaps — valid level range and any expectation of the response format — are notable precisely because no structured metadata exists to fill them.
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 schema offers only a bare integer 'level' with no explanation. The description compensates partially by tying the parameter to its purpose ('at a given level'), which tells the agent the level selects which stat row to fetch. It stops short of providing a valid range, bounds, or level-scaling behavior, so the compensation is incomplete.
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 description names a specific resource ('Soul-Arms base stats') and a precise scope ('at a given level'), and adds semantic clarity by specifying the stats are 'flat Attack/HP/Tenacity added to a hero.' This distinguishes it from sibling item-lookup tools like get_talent, get_insignia, or get_equipment by subject matter, though it never explicitly names a sibling or states what it is not.
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 the many sibling lookup tools, no exclusions, and no mention of alternatives. Usage is only implied: choose this tool when the agent needs Soul-Arms base stats by level. Among roughly 40 siblings including get_talent, get_crest, and get_enchantment, the description offers no routing help.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does convey that this is a read-only listing operation sorted by tier and that tier/mode act as filters, which is meaningful behavioral information. However, it does not mention output format, pagination, limit behavior, or what happens when tier is null, leaving some behavioral gaps.
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 core purpose is front-loaded, and the parameter examples are compact and scannable. Every sentence earns 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?
For a simple, low-complexity tool with no required parameters, the description is mostly adequate: an agent could invoke it with defaults or use the stated mode/tier hints. But it omits limit semantics, return value expectations, and any differentiation from the closely named sibling 'tier_list'. Given no output schema and no annotations, these omissions leave the context incomplete.
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 for the bare schema. It adds helpful semantics for 'mode' with examples ('overall/Guild War/Arena/Dungeons') and for 'tier' with filter examples ('S+, S, A+...'), which goes beyond the schema. The 'limit' parameter is not explained at all, even though it has a numeric default, so the compensation is only partial.
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 description clearly states the action and resource: 'List heroes ranked by tier,' so an agent understands what the tool does. It also gives concrete examples for mode and tier, which makes the purpose more specific. However, it does not explicitly distinguish this tool from the sibling 'tier_list', which appears to overlap in function.
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 instead of alternatives. Sibling tools like 'tier_list', 'rank_heroes', and 'get_hero' suggest related use cases, but the description does not explain how to choose among them. The mode and tier examples imply a browsing context, but no explicit when-to-use or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden; it does disclose that the stat is computed, that stars/level are inputs, and that newest epics may be missing from results. However, it does not disclose sorting order, output shape, or how limit is applied, which are meaningful for a ranking tool.
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?
Two sentences with the action and key constraints front-loaded, plus a useful data-freshness caveat at the end. There is no filler, repetition, or unnecessary detail.
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 description is adequate for basic invocation since all parameters are optional and the core behavior is stated, but it omits the return shape, sorting direction, and limit semantics. Without an output schema or annotations, these gaps make it only minimally complete.
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 clarifies stat ('HP/Attack'), stars, and level, but says nothing about 'limit', leaving its semantics to be inferred from its name and default value.
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 description names a specific action ('Rank'), resource ('heroes'), and core dimensions ('computed stat (HP/Attack) at given stars/level'). It is clear enough to be distinguished from siblings like compare_heroes or hero_stats, though it does not explicitly name a differentiating sibling.
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?
No guidance is given for when to use rank_heroes instead of alternatives such as hero_stats or compare_heroes, and no exclusions or prerequisites are stated. The intended use is only implied by the verb 'Rank' and the stat/level parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations and no output schema, so the description carries the full burden of explaining behavior. It only states the search scope and provides examples; it does not disclose what the returned results look like, whether limit applies per system or across all results, or any other behavioral traits.
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 one short, efficient sentence that front-loads the key fact—the all-systems scope—and uses examples to clarify the resource types. No wasted words.
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?
Given a large sibling list, no annotations, no output schema, and 0% schema description coverage, the description is too sparse. An agent knows this searches broadly, but not enough about result structure, limit semantics, or how this tool differs from the many related lookup/search siblings to use it with full confidence.
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?
Schema description coverage is 0%, so the description needed to compensate for the undocumented query and limit parameters. It adds only that searching covers game systems; it gives no detail about query syntax, matching behavior, or how the limit parameter behaves.
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 names a specific action (Search) and an exact resource (ALL 28 game systems at once), with a clear list of example domains. It distinguishes itself from narrower sibling lookup tools and makes its broad scope immediately obvious.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'across ALL 28 game systems at once' phrasing implies this is the tool for broad, cross-system search rather than a single-system lookup. However, it never explicitly says when not to use it or names an alternative such as search_game_data for narrower searches, leaving some routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It does disclose that the tool returns exactly one entry and includes full per-level/per-star data, which is useful. However, it does not mention exact-name matching, error behavior, output format, or whether partial names are accepted.
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 one compact sentence with three illustrative examples. It is front-loaded, contains no filler, and the examples add meaningful context without bloating the text.
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 description is sufficient to attempt a call when the system and English name are known, but it leaves gaps around the full set of valid systems and how this tool relates to specialized siblings. Given no output schema or annotations, more context would improve reliable tool selection.
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?
The schema has no parameter descriptions, so the examples provide the main semantic guidance: system appears to be a category like 'holy', 'crest', or 'gear', and name is the English entry name. This helps but does not fully define accepted system values or name syntax.
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 description states a clear lookup operation: one entry from a system by English name, returning full per-level/per-star data. The examples make the resource type concrete, though it does not explicitly differentiate itself from sibling tools like get_crest or get_equipment.
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?
No explicit guidance about when to use system_lookup versus alternatives. Examples show call shape, but the description does not explain when this generic lookup is preferable to specialized sibling tools or what kinds of names/systems are valid.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It conveys a read-only list operation, but it fails to disclose that the optional limit defaults to 300, which creates tension with the promise of listing 'all' entries. No mention of pagination, ordering, or payload size is provided.
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 a single front-loaded sentence with no filler. The verb and object appear first, and the category examples are packed into parentheses without bloating the core message.
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?
For a simple list operation, the primary use case and expected result are mostly clear. However, the description is incomplete because it omits the effect of limit, does not direct users to list_categories for valid category names, and no annotations or output schema fill those gaps.
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?
Schema description coverage is 0%, so the description must compensate. It gives helpful examples for the category parameter, but it says nothing about the limit parameter and does not explain how limit interacts with the 'all entries' behavior.
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 uses a specific verb ('List'), a clear resource ('entries in a catalog category'), and a rich set of example categories. It is immediately distinguishable from siblings like get_catalog_entry and list_categories.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly scopes the tool to listing catalog entries and gives representative category values, so usage context is inferable. However, it never explicitly says when to prefer this tool over alternatives such as get_catalog_entry for a single entry or list_categories for category names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It discloses the source ('decoded Skill.data'), the output kind (per-level effect + English description), and accepted input forms, but it does not describe the return shape, unknown-skill behavior, or whether this is purely read-only.
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?
Two short sentences, with the core output and scope front-loaded and the parameter clarification placed directly after. Every word earns 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?
For a tool with one required parameter and no output schema, the description gives the essential selection and invocation information: what it returns and how to fill 'skill'. However, it lacks any relationship to sibling skill tools and does not illustrate the shape of the returned per-level data, so the agent still has some uncertainty.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only declares a required string 'skill', so the description compensates by defining it as a skill name or numeric name_id and giving a concrete example. This is meaningful semantic information for the only parameter, though it does not specify the exact format of numeric name_id.
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 description clearly states that the tool provides per-level effects and English descriptions for game skills, with a concrete example input ('Divine Shield'). The scope ('421 game skills') is specific and the operation is obviously a lookup, but it does not explicitly distinguish itself from siblings like skill_data or skill_damage.
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 choose this tool over skill_data, skill_damage, or effect_at_level. The description implies a generic lookup use case but gives no exclusions, prerequisites, or alternative selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of explaining behavior. It discloses the return content (each reward with weight and probability %) and the fallback list behavior for unknown or omitted types. It does not address the contradiction between 'omit' in the description and 'required' in the schema, nor other edge cases.
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 concise sentences with no filler. The core purpose is front-loaded, and the fallback behavior is stated separately and clearly.
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?
For a one-parameter tool without an output schema, the description covers the return format and the main special case. However, the conflict between 'omit' and the required schema leaves the agent uncertain about how to actually make the call, and no valid enum values or examples are provided.
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 is the only explanation of the pool_type parameter. It explains that the parameter selects the pool type and that an unknown/omitted value returns the available types, which is a practical way to discover valid values. It does not define what the integer values represent or how to trigger the fallback deliberately.
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 description clearly states the tool returns drop odds for a gacha pool, including reward weight and probability percentage. It identifies the relevant parameter ('by Type') but does not explicitly differentiate this tool from its many sibling data-lookup tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a useful discovery path: omitting or passing an unknown pool type returns the list of available pool types. However, it does not provide when-not-to-use guidance or mention alternatives, and the omission advice conflicts with the schema marking pool_type as required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It enumerates exactly what the record includes: combat stats, base per evolution, full level curves for forms 1-80, main skill per level, totem skill, and icon. This gives an agent a solid picture of the tool's output without needing an output schema.
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 one compact, front-loaded sentence that lists the key contents immediately. Each phrase adds substantive information, with only minor redundancy between 'authoritative' and 'all-in-one.'
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 description gives a good inventory of return fields, which matters since there is no output schema or annotations. However, it omits parameter format guidance and does not clarify which sibling tools cover narrower use cases, leaving some contextual ambiguity for an agent choosing among hero_complete, get_hero, hero_stats, and hero_sheet.
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?
The input schema has one required 'hero' string with no description, and schema description coverage is 0%. The description never explains what value 'hero' should take—whether a name, ID, alias, or display name—nor how to format it. This is a notable gap for a tool with a single critical parameter.
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 description clearly identifies a comprehensive, single-hero resource and enumerates its contents (combat stats, evolution bases, level curves, skills, icon). It is distinguishable from narrower siblings like hero_stats, totem_skill, and get_hero, though it does not explicitly name them or use a specific verb.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'authoritative all-in-one hero entry' implies this tool is for cases where the full hero record is needed, but the description does not explicitly state when to use it versus alternatives such as hero_stats, totem_skill, or get_hero. No when-not-to-use or alternative routing is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does well by disclosing data provenance: ordinary stats are formula-verified, evolved grades come from live_hero_params, and a reconciliation flag exists for multi-form mis-extraction. It does not describe output structure or error behavior, but this is meaningful contextual detail beyond a generic summary.
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?
Two dense sentences with the main purpose front-loaded. The first sentence enumerates the included content, and the second adds verification and flag behavior. Every clause contributes useful information, with no filler or repetition.
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 description covers what data is returned and how some of it is validated, making it sufficient for tool selection. However, invocation is incomplete: the accepted hero identifier format is unspecified, there is no output schema, and no guidance about reconciling with sibling tools. It is adequate but not fully complete for a complex aggregator.
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?
The schema only defines a required string parameter named 'hero', and schema description coverage is 0%. The description says 'one hero' but never specifies what format the hero value should take, whether it is an ID, display name, slug, or how to resolve valid values. With zero schema coverage, the description should compensate but does not.
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 description clearly defines the tool as a one-call hero aggregator and lists the specific content it returns: combat ratings, evolution-grade formula parameters, HP/ATK values, skills, tier/role, and a recommended build. This effectively distinguishes it from narrower sibling tools like get_hero, hero_stats, or hero_skills, though it does not explicitly name them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use case is implied: use this when you want comprehensive hero information in a single call. However, the description never explicitly says when not to use it or which alternative tools cover narrower cases, despite many overlapping siblings like get_hero, hero_sheet, hero_stats_calc, and recommend_build.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It correctly describes the operation as a listing of categories with counts, and there is no indication of destructive or side-effect behavior. However, it does not explicitly mention limitations such as whether all categories are included, ordering, or whether the data is live or cached.
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 a single, front-loaded sentence that states the core purpose and then provides illustrative examples. There is no filler or redundant wording, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, parameterless listing tool, the description covers the essential information: what is being listed and what is returned. It could be slightly more explicit about the relationship to the broader catalog and whether the category list is exhaustive, but the examples with an ellipsis suggest the category set is open-ended.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so parameter-level documentation is unnecessary. The description adds meaningful context about what the categories represent through its examples, which is sufficient for a parameterless list operation.
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 description clearly states the action ('List catalog categories') and the output ('how many entries each has'), which makes the tool's purpose easy to understand. It does not explicitly compare itself to siblings like list_catalog or get_catalog_entry, so some differentiation is left to inference.
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 about when to use this tool versus the many sibling tools that deal with catalog data, such as list_catalog or get_catalog_entry. The intended use case is implied by the purpose, but no explicit when-to-use or when-not-to-use information is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It does explain the output composition (complete game data merged with tier and build tags), but it does not mention error behavior, name matching semantics, or whether the operation is a pure read with no side effects.
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 a single, well-structured sentence that front-loads the core purpose ('Full hero record') and then enumerates the included data categories in a compact parenthetical list. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter lookup with no output schema, the description gives a solid inventory of what the returned record contains: combat data, evolution bases, level curves, skills, totem, icon, and tier/build tags. It is mostly complete, though it could be improved by clarifying name matching and not-found behavior.
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%, and the description does not explicitly explain the 'name' parameter. However, with only one required parameter and the tool named get_hero, it is reasonably clear that 'name' identifies which hero to retrieve, even though exact-name/format requirements are not documented.
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 description clearly defines what the tool returns: a complete hero record with game data merged with tier and build tags. It is more specific than just 'get hero', but it does not explicitly distinguish itself from similarly named siblings like hero_complete or hero_dossier.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Full hero record' and 'complete game data' imply this is the tool to use when all hero information is needed, not just a specific stat or skill. However, there is no explicit when-to-use or when-not-to-use guidance relative to the many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the core behavior: rebuilding the database, loading the seed catalog, and scraping casclash unless seed_only is set. However, it does not explicitly warn that this likely overwrites/destroys existing data, nor does it mention runtime, network dependence, or auth requirements.
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?
One dense, front-loaded sentence conveys the main purpose and parameter behavior without filler. Every phrase earns 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?
Given there is no output schema and no annotations, the description leaves some gaps: no mention of return behavior, no explicit destructive-data warning, and no operational caveats such as duration or required permissions. It covers the input semantics well but is not fully complete for a database-rebuilding tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description directly explains both parameters: seed_only toggles scraping off, and limit caps the number of heroes scraped. This adds meaningful semantics beyond the bare schema types and defaults.
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 starts with the specific verb phrase 'Rebuild the database', clearly identifying the resource and the operation. It further specifies the two main actions (load seed catalog, scrape casclash) and the conditional behavior, which distinguishes it from the many read-only sibling 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?
The description explains what the tool does but gives no guidance on when to use it versus alternatives, nor any conditions or exclusions. There is no mention of how this relates to the other data tools or when a caller should prefer seed_only vs full scrape.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It clearly states the broad scope and the output shape, which is useful. It does not mention performance implications of searching 182 tables, ordering, pagination, or whether results are read-only, though 'search' strongly implies a non-mutating operation.
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?
Two short sentences deliver the essential scope and output information with no filler. The most important fact (searching all tables) is front-loaded, and the return behavior is stated immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity tool with only one required parameter, the description is largely sufficient: it names the search scope and the output. The main gaps are lack of explicit parameter semantics and absence of any note about result limits or performance, but the schema partially fills the limit default and the tool is simple enough that an agent can invoke it correctly.
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?
Schema description coverage is 0%, so the description must compensate for parameter meaning. It does not explicitly explain that 'query' is the search text or describe how 'limit' affects results. The full-text search phrasing makes the query parameter inferable, but the limit parameter and any query syntax expectations are left to the schema alone.
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?
Describes a specific action ('full-text search') with a clear resource scope ('ALL 182 game tables') and a concrete result ('Returns matching rows with their table name'). This distinguishes it from sibling lookup tools like get_hero or list_heroes, which target specific tables or entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is the right tool when you need to search across the entire game dataset rather than retrieving a known entity from a specific table. However, it gives no explicit guidance on when NOT to use it or how it relates to the targeted sibling tools, so the agent must infer the intended use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It transparently explains that stats are live and come via an unofficial third-party calculator, and it clarifies parameter semantics like reincarnation=1 meaning the normal evolved form. It does not cover error behavior or data freshness, but for a read-only calculator it is reasonably transparent.
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 is dense but every sentence contributes: source, returned stats, parameter formats, and special values. It could be slightly better organized, but it is appropriately sized for a parameter-heavy tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 10-parameter schema with zero description coverage and no output schema, the description does a strong job of making the tool callable. It explains most non-obvious parameters and enumerates return fields. Minor gaps remain around skill_lvl, camp_lvl, and output formatting, but these are not severe.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/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 documents level range, talent name/id format, talent_lvl range, reincarnation meaning, and numeric id semantics for camp/pet/inscription. However, it leaves camp_lvl and skill_lvl unexplain beyond their schema defaults.
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 description clearly states the tool computes live, fully-computed hero stats and lists exactly which stats are returned. It distinguishes itself by noting it uses casclash's calculator rather than an official IGG API, though it does not explicitly differentiate from sibling tools such as hero_stats_calc or hero_level_stats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when you need final computed stats at a given level. However, it does not explicitly state when not to use it or mention alternative sibling tools that might be more appropriate for raw data, formulas, or partial stat lookups.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden and largely meets it: it clarifies this is a non-fight calculation ('without a fight'), gives the offense formula, and cites 'verified combat math' as credibility. It doesn't explicitly state read-only/no-side-effect behavior, but pure computation is strongly implied.
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?
Two sentences deliver the core purpose, output metrics, formula, data-source caveat, and a shape-sharing hint. Every clause earns its place and the content is front-loaded.
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 definition covers what is computed and the intended comparison use case, but with no output schema and seven parameters it leaves gaps: the range/meaning of the 'grade', the exact effective stats returned, and the semantics of most parameters are missing.
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?
Schema description coverage is 0%, so the description needed to explain the parameters. It only explains that loadout_json has the same shape hero_stats_calc accepts; hero, evo, level, stars, talent, and talent_lvl are left without additional meaning.
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 opens with a specific verb ('Grade a build') and names exact outputs: effective stats, EHP, and an offense score formula. It also differentiates from fight/simulation siblings by saying 'without a fight' and narrows scope to 'compare builds on one hero.'
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?
It explicitly states the intended use case: comparing builds on one hero. It also gives a shape-sharing hint with hero_stats_calc, but it doesn't name the tools this should replace or state explicit when-not-to-use conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral disclosure burden. It transparently lists the categories of issues it flags and states that it returns 'findings + ok,' giving the agent a clear model of what the tool checks and returns. It omits side-effect and auth details, but for a validation tool this is reasonable.
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 sentences with no filler, front-loading the action and then adding concrete details about checks and return value. Every clause earns 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 description covers the tool's core purpose and return shape, which is adequate for a simple validation tool. However, with no annotations and no output schema, it leaves gaps around parameter details and usage guidance that would help an agent invoke it correctly in a broader workflow.
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?
Schema description coverage is 0%, so the description must compensate for the six undocumented parameters. It does not explain hero, pet, crest, talent, insignia, or enchantment, nor how they map to the '5-slot' concept. The parameter names are self-explanatory, but no meaning is added beyond what the schema already shows.
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 uses a specific verb ('Validate') and identifies the resource ('5-slot build'), then enumerates concrete checks: reflection redundancy, energy gaps, missing reflection/ATK, signature-talent HP penalties, and revive suggestions. This makes it distinct from sibling build-related tools like build_score or generate_build.
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 clearly implies the tool is for validating an existing build configuration, which gives clear context. However, it does not explicitly state when to prefer check_build over alternatives such as build_score or recommend_build, nor does it list exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the return values (expected winner, DPS, crit chance with opponent's Tenacity, time-to-kill), names the optional reduce_a/reduce_b inputs, points to the math reference, and clearly states model limitations. It does not explicitly say the simulation is deterministic or side-effect-free, but 'simulate' plus the detailed scope conveys the expected behavior well.
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 three tightly written sentences with no fluff. The first sentence states the core action and scope, the second lists the return values, and the third clarifies optional parameters and limitations. Every sentence earns its place and the most important information is front-loaded.
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?
For a complex tool with 11 parameters, no output schema, and no annotations, the description provides a solid overview of outputs and limitations, but it omits parameter-level guidance for the majority of inputs. An agent could still be uncertain about how evo, level, stars, and talent fields combine to form a build, or what 'damage-reduce ratings' mean exactly. The return list is helpful but not enough to fully compensate for the lack of schema descriptions.
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?
Schema description coverage is 0%, so the description must compensate for 11 parameters, but it only explains reduce_a/reduce_b. The hero_a/hero_b parameters are inferable from their names, but evo, level, stars, talent_a, talent_b, talent_a_lvl, and talent_b_lvl receive no semantic explanation in either the schema or the description. This leaves significant room for misunderstanding how these parameters shape a 'hero build.'
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 uses a specific verb ('Simulate') and resource ('1v1 auto-attack duel between two hero builds'), and clearly distinguishes it from skill-related sibling tools by stating that skills, energy, heals, shields, and crowd control are not modeled. It also names the verification source and the expected outputs, leaving no ambiguity about what the tool does.
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 communicates the intended use case: an auto-attack, damage-formula-based duel between two hero builds. It also states explicit exclusions ('Skills, energy, heals, shields and crowd control are not yet modeled'), which tells the agent when not to use it. However, it does not name specific sibling tools or provide explicit alternative routing, such as 'use combat_effects for full combat logic.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It reveals that the tool performs pure numeric/stat ranking, supports three named objectives, and scores talent and crest together. It does not disclose return format, error behaviors, or whether hero name requires normalization.
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?
Two sentences with no filler. The first sentence front-loads the action, inputs, and output; the second gives a clear cross-check directive. Everything earns 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?
Without an output schema or annotations, the description explains the core operation and output adequately but omits parameter defaults, valid/expected value formats, and the relationship to the sibling build_score tool. It is enough for a basic call but not fully self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/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 does meaningfully: objective is explicitly given valid values ('offense', 'ehp' or 'balanced'), top is implied by 'top options per slot', and talent_lvl/crest_level are implied by 'talent + crest scored together'. Hero is obvious from context.
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 clearly states the tool's function: it ranks talent and crest slots for a hero using build_score for an objective and returns the best full build plus top options per slot. This distinctive combination of ranking, scoring, and build selection separates it from siblings like check_build or recommend_build.
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 provides explicit guidance to cross-check recommend_build when pure stat ranking is involved, naming the alternative and the caveat. It does not enumerate exclusions versus all siblings, but it gives a concrete decision signal for when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It discloses the output category (path), the parameter relationship (kind selects map, key selects item), and the list behavior when key is omitted. It doesn't discuss error/unknown-kind behavior, but for a read-only lookup this is a minor gap.
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?
Two short sentences with no filler, and the most important fact (result is an icon path) is front-loaded. The parenthetical and the 'omit key' instruction each add distinct value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-param lookup with no output schema, the description covers the return type, the controlled vocabulary source (icon_maps), and a discovery mechanism (omit key). It does not explain where icon_maps lives or error behavior, but the built-in listing compensates for discoverability.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain both params. It does: kind selects an icon map for hero/skill/item/pet, and key is optional and, when omitted, triggers listing of kinds. It doesn't enumerate valid key strings or exact formats, but gives enough functional meaning.
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 description identifies the tool's output (icon path) and scope (hero/skill/item/pet) and introduces the kind concept from icon_maps. It lacks an explicit verb like 'returns,' but the second sentence ('Omit key to list icon kinds') makes the function clear. No sibling tool competes for icon lookups, so differentiation is inherent.
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?
It gives actionable usage context: pass a kind to get a path, omit key to list icon kinds, and source the kind from icon_maps. It doesn't name alternatives or when-not conditions, but no sibling icon tool exists and the context is clear enough for an agent to use it correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It explains the stat formula, evolution parameter source, talent percentage application, type semantics for inscription/soularms/artifact, gear_json format, and the effective-stats output. This is substantial transparency, though some edge behaviors remain unstated.
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 dense but every sentence earns its place: formula, validation example, talent behavior, sibling preference, and parameter semantics are all included. Given the tool has 16 parameters, the length is justified and information is well front-loaded.
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?
For a complex tool with no annotations and no output schema, the description provides a strong foundation but still leaves meaningful gaps. Several input parameters are not explained, and the exact expected format for loadout_json is missing. An agent would likely still be uncertain about how to populate all schema fields correctly.
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?
The schema has 0% description coverage, so the description must compensate. It adds real meaning for talent/talent_lvl, evo, inscription/soularms/artifact, and gear_json, but it leaves several parameters unexplained, including crest_name, crest_level, pet_talent, pet_talent_level, loadout_json, and soul. This is partial but not complete compensation.
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 clearly states that this is a formula-based hero stat calculator, provides the formula, and validates it with a concrete example. It also explicitly distinguishes itself from the sibling hero_stats tool by noting that hero_stats caps stars at 4, so purpose and differentiation are both strong.
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 explicitly says to prefer this tool over hero_stats because hero_stats caps stars at 4, which is a clear usage signal against the closest alternative. However, it does not fully map out when to use this versus all other sibling tools, so it is not a perfect 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the tool's output (row counts, refresh timestamp) and the verb 'Show' implies a read-only operation. It does not explicitly state side effects or return format, but for a simple status query this is adequately transparent.
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?
A single, front-loaded sentence with no wasted words. It states the verb and object clearly and nothing more.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter status tool, the description covers what the tool does and what information it surfaces. It does not specify the return shape or which tables are counted, but that omission is minor given the tool's simplicity and the absence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the input schema provides no meaningful details. The baseline of 4 applies, and the description does not introduce any parameter-related ambiguity.
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 uses the specific verb 'Show' with a clear resource: row counts and the last refresh time of the data. This clearly distinguishes db_status from all sibling tools, none of which appear to report database status or freshness.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance about when to use this tool or when to prefer an alternative like refresh_data. However, the description implies its purpose: to inspect data freshness and row counts, which an agent can reasonably infer as a precursor to data-dependent queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden and does disclose a non-obvious behavior: pet bonuses are team-wide auras and are excluded from hero_stats_calc's per-hero flat stats. It also lists the lookup return fields. It omits error/edge-case behavior, but for a simple read lookup this is acceptable.
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?
Two tight sentences with no filler; the core lookup purpose is front-loaded and the important cross-tool caveat is attached as a short note.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter lookup tool with no output schema, the description states the input context and the fields returned, and flags the team-wide aura nuance. It could add an example or mention invalid-name behavior, but nothing critical is missing.
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?
The schema exposes a single required string 'name' with no description (0% schema coverage), and the description does not explicitly explain the accepted format. However, 'Pet lookup' makes it reasonably clear that 'name' is the pet name, so the description provides minimal compensating context.
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?
Description begins with a specific verb+resource ('Pet lookup') and explicitly names the Pet table, plus the returned fields (id, mark, pet-talent). It also distinguishes itself from hero_stats_calc by noting pet auras are not included in that tool's per-hero stats.
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 note that pets give a team-wide aura and are 'browsable here but not folded into hero_stats_calc's per-hero flat stats' gives a clear context for when to use this tool instead of the stat calculator. It does not name other alternatives or broader exclusions, so it is not a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly explains the tool's polymorphic behavior: skill points to heroes, hero points to skill, item points to system. It does not mention ambiguity handling, exact-match behavior, or output format, but the core behavioral logic is well conveyed.
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 a single compact sentence with a parenthetical example list that illustrates the behavior without adding fluff. The main verb and resource are front-loaded, and every clause contributes to understanding the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity of a single-parameter lookup tool and no output schema, the description covers the essential selection and invocation needs: what input is expected, what types are resolved, and what relationships are returned. The main omissions are the exact return shape and handling of ambiguous names, but these are minor for basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter is 'query', and schema description coverage is 0%, so the description must compensate. It does this by clarifying that the query is a name and that it may refer to a hero, skill, or catalog item. It stops short of specifying matching syntax or formatting requirements, but for a single string parameter, the semantic guidance is adequate.
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 uses a specific verb ('cross-reference') and a clear resource scope ('any name'), then explicitly defines the three possible result categories: hero, skill, or catalog item. It also explains the directional connections returned for each type, which distinguishes it from the many sibling retrieval tools like get_hero or get_catalog_entry.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: whenever a name needs type resolution and relation discovery. However, it does not explicitly contrast this with sibling tools such as search_all, system_lookup, or get_hero, nor does it state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral disclosure burden. It does so well by revealing an important limitation: '274 of 426 skills carry a real damage coefficient,' warning the agent that some skills will lack this data. It also clarifies that returned damage is a percentage, not an absolute number, which prevents misinterpretation.
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?
Two concise sentences with no filler. The core data content is front-loaded, followed by a useful caveat about coverage, then a direct pointer to the alternative tool. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter lookup with no output schema, the description covers the source, the fields returned, the percentage semantics, the coverage limitation, and the relevant sibling for conversion. It does not describe the exact return shape or how missing coefficients are represented, but those are minor gaps given the tool's simplicity and the fields listed.
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?
The schema provides only a single required 'skill' string parameter with no description, and schema description coverage is 0%. The tool description names 'skill' but does not specify whether it expects a skill name, ID, or other identifier. Since the parameter name is self-explanatory and there is only one parameter, this is adequate but leaves some ambiguity for an agent.
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 names a specific resource (Skill.data), a precise verb class (returns numeric per-level data), and the exact fields returned: damage % of ATK, targets, duration, effect %. It also distinguishes itself from its sibling skill_damage by noting that this tool returns raw percentages, not actual numbers. An agent can tell this tool apart from related siblings without opening any schemas.
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 explicit but partial routing guidance: 'Use skill_damage to turn a % into an actual number.' This tells the agent when to choose skill_damage instead of this tool for damage conversion. It does not enumerate other when-to-use / when-not-to-use cases versus the many sibling data-lookup tools, but it provides enough context for the most likely decision.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for safety and behavior. It clearly signals a read-only listing operation with no side effects, and adds useful context that the data is extracted from the APK and that the result set has exactly 182 tables. It does not describe the return format, but for a zero-argument list tool that is a minor omission.
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 a single efficient sentence that front-loads the action and resource, then gives representative examples. Every element adds value and there is no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list tool with no output schema, the description is fully sufficient: it names the exact data source, scope, and content categories. An agent can invoke it correctly without additional information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description appropriately focuses on the resource scope rather than parameters, which is all that is needed here.
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 uses a specific verb ('List'), a precise resource ('game data tables extracted from the APK'), and an exact scope ('all 182'), distinguishing it from more focused sibling tools like list_heroes or list_catalog. The category examples further clarify the resource without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied: call this tool to see the full set of game data tables available from the APK. However, it does not explicitly state when to prefer this over siblings like list_categories or list_catalog, nor does it mention any exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full behavioral disclosure. It explains what data is returned for each input mode and adds interpretive context (status bits mapping to crowd control, type 39 = hard CC, type 3 = immunity/cleanse). It doesn't explicitly state read-only behavior, but the reference-taxonomy language strongly implies no mutation.
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?
Three dense sentences deliver all essential information with no filler. The purpose is front-loaded, followed by mode-specific behavior and useful encoding examples. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one optional parameter, the description covers both modes, mentions the exact count (59 BufferTypes), and explains the semantic mapping of status bits. It doesn't specify the output schema, but no output schema is provided and the return shape is reasonably inferable from the content described.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only shows buffer_type as an integer/nullable field, so the description must compensate for the low coverage. It does so thoroughly: it explains that supplying buffer_type returns that type's mechanic and state bit, and gives concrete value mappings (39, 3) that help the agent use the parameter meaningfully.
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 clearly states the resource (effect-engine taxonomy) and the two distinct actions: aggregating counts by handler category or retrieving a specific buffer type's mechanic and state bit. It differentiates itself from siblings like combat_math or simulate_fight by describing a unique reference taxonomy, not calculations or simulation.
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?
It gives explicit usage context for both invocation modes: no argument returns category counts, buffer_type returns specific mechanics. It doesn't name alternatives, but it provides enough conditionality for an agent to decide which call to make in a given scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and it discloses key behavior: results come from fixed tables, are exact/authoritative, not formula-computed, and are scoped to Lv1-80 and specific evolutions. It does not describe return formatting or error behavior, but the core lookup behavior is transparent.
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?
Two dense sentences: the first front-loads the exact lookup behavior and source, and the second adds valid values and the routing alternative. No filler words; every clause conveys necessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 3-parameter lookup with no output schema, the description is nearly complete: it names the returned stats, valid input range, evolution options, and the alternative for out-of-scope requests. It could specify the exact hero identifier format, but this is a minor gap given the surrounding toolset like list_heroes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover 0% of parameters, so the description must compensate. It documents the evo enum values and the level range (Lv1-80), adding meaning beyond the bare schema. The hero parameter is left to be inferred from the tool name, but the other parameters gain useful constraint information.
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 explicitly states the tool returns EXACT per-level HP/Attack/MOV/Might values from a specific source (casclash's tables), covering Lv1-80 per evolution. It distinguishes itself from hero_stats_calc by noting the table-based, authoritative, formula-free nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear when-to-use conditions: use this tool for exact table values at levels 1-80 and for the listed evolutions, and explicitly directs to hero_stats_calc for level >80 or higher stars. Valid evo values are enumerated, leaving no ambiguity about acceptable inputs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

castle-clash-mcp MCP server — quality and maintenance score on Glama

Copy to your README.md:

[![castle-clash-mcp MCP server — quality and maintenance score on Glama](https://glama.ai/mcp/servers/mmadersbacher/castle-clash-mcp/badges/card.svg)](https://glama.ai/mcp/servers/mmadersbacher/castle-clash-mcp)

Score Badge

Copy to your README.md:

[![castle-clash-mcp MCP server — quality and maintenance score on Glama](https://glama.ai/mcp/servers/mmadersbacher/castle-clash-mcp/badges/score.svg)](https://glama.ai/mcp/servers/mmadersbacher/castle-clash-mcp)

shields.io Endpoint

For READMEs with an existing badge row. Append &style=flat-square (or any other shields.io style) to match the rest, and &metric=tools, &metric=maintenance or &metric=claim to badge a different dimension.

[![castle-clash-mcp MCP server — quality and maintenance score on Glama](https://img.shields.io/endpoint?url=https%3A%2F%2Fglama.ai%2Fmcp%2Fservers%2Fmmadersbacher%2Fcastle-clash-mcp%2Fbadges%2Fshields.json)](https://glama.ai/mcp/servers/mmadersbacher/castle-clash-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/mmadersbacher/castle-clash-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server