Clash Royale

Clan

clan

Read-onlyIdempotent

Clash Royale official API — full clan profile for a clan tag: name, description, type, score, member count, trophies required, and war trophies.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`tag`	Yes

Output Schema

TableJSON Schema

Name	Required	Description
`tag`	No	Clan tag identifier
`name`	No	Clan name
`type`	No	Clan type
`badgeId`	No	Badge ID
`members`	No	Clan members list
`location`	No	Clan location
`clanScore`	No	Clan score
`description`	No	Clan description
`memberCount`	No	Number of members
`clanChestStatus`	No	Clan chest status
`clanWarTrophies`	No	Clan war trophies
`donationsPerWeek`	No	Donations per week
`requiredTrophies`	No	Required trophies to join

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedMay 27, 2026

addedInput schema / examples

Added value: +[
+  {
+    "tag": "#2CCCP"
+  }
+]

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "badgeId": {
+      "description": "Badge ID",
+      "type": "number"
+    },
+    "clanChestStatus": {
+      "description": "Clan chest status",
+      "type": "string"
+    },
+    "clanScore": {
+      "description": "Clan score",
+      "type": "number"
+    },
+    "clanWarTrophies": {
+      "description": "Clan war trophies",
+      "type": "number"
+    },
+    "description": {
+      "description": "Clan description",
+      "type": "string"
+    },
+    "donationsPerWeek": {
+      "description": "Donations per week",
+      "type": "number"
+    },
+    "location": {
+      "description": "Clan location",
+      "type": "object"
+    },
+    "memberCount": {
+      "description": "Number of members",
+      "type": "number"
+    },
+    "members": {
+      "description": "Clan members list",
+      "type": "array"
+    },
+    "name": {
+      "description": "Clan name",
+      "type": "string"
+    },
+    "requiredTrophies": {
+      "description": "Required trophies to join",
+      "type": "number"
+    },
+    "tag": {
+      "description": "Clan tag identifier",
+      "type": "string"
+    },
+    "type": {
+      "description": "Clan type",
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

First observedMay 20, 2026

TDQS

B3.2/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds a small amount of context by listing what fields are included, but does not disclose any other behavioral traits (e.g., error handling, tag format). It does not contradict the annotations.

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, focused sentence that front-loads the API source and the core purpose. It lists fields efficiently without redundancy or fluff, earning 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, single-parameter read tool with an output schema and rich annotations, the description is adequate. It conveys the core function and field list. It does not describe return values, which is acceptable given the output schema, and does not need to explain safety due to annotations. Minor gaps like tag formatting are covered by the schema example.

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% for the 'tag' parameter, so the description must compensate. It clarifies that the tag is a clan tag, but it does not specify the required '#' prefix format or any validation rules. The example in the schema provides the format, but the description alone adds minimal semantic value beyond the parameter name.

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 a full clan profile by tag and lists specific fields (name, description, type, score, member count, trophies required, war trophies), which distinguishes it from narrower sibling tools like clan_members or clan_current_war. However, it lacks an explicit action verb like 'retrieves' or 'gets', making the purpose slightly implicit.

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 no guidance on when to use this tool versus alternatives. It does not mention that clan_members should be used for member lists or clan_current_war for war details, nor any exclusions or prerequisites. The context is entirely absent.

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

All Clash Royale tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.