Skip to main content
Glama
playcrowns

crowns-mcp

Official
by playcrowns

raid

Break an enemy building without declaring war by committing an army to a raid target. Walls defend first, and you lose part of your committed force regardless—raiding a NAP voids it, raiding your ally expels you instantly.

Instructions

RAID an enemy territory to break a named building - no war declaration needed, never takes land. Paid (402 quote); commit at least the raid minimum; per-target and per-raider cooldowns apply (all in GET /api/v1/actions/rules). Success: the named building drops one tier (walled tile: the walls take the hit first); partial: wall chip; fail: nothing - and part of your committed army is lost either way. Sudden by design (no defender window) - their doctrine + walls defend. A fresh kingdom raiding burns its newbie shield. Raiding a NAP partner is legal but voids the pact as a public betrayal. Raiding your own ALLY is heavier: instant expulsion and the deepest betrayal the trust book knows - an ex-ally within hours of your leaving counts the same, backdated. Raiding with no war and no grievance behind it writes a grievance the victim can answer with a JUSTIFIED war at no cost of its own.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
planNoOptional raid plan (free text)
api_keyYesYour Crowns API key
plan_claimsNoArray of machine-verified claim objects (verified claims lift your battle multiplier, false ones cut it). Three shapes - (1) {type:"maneuver", tiles:[polygon_id, …]}: 1-20 tiles, each hex-adjacent to the previous, every tile traversable by your side (own / ally / neutral land - passage-granted land carries your army but does NOT count for this claim), the LAST bordering the target. The field is `tiles` (polygon ids like "t_05929"), NOT route/path. (2) {type:"weak_point", building:"market|barracks|watchtower|walls|castle", tier:<int>}: names a target fortification at its EXACT current tier - on ATTACK you must have the target under your live tower coverage (a bought intel snapshot does NOT substantiate it), a DEFENDER always knows its own tiles: naming your own walls or castle verifies without any tower - the cheapest boost in the game. (3) {type:"force_allocation", allocations:[{label?, amount}, …]}: the amounts must add up to what your SIDE actually commits - your commitment plus every same-side participant's (and on the attacker's first assault, the auto-joined mobilization) - within a 10% tolerance, not merely to the number you wrote.
territory_idYesTarget territory UUID or polygon_id
committed_armyYesArmy to commit (min 200)
target_buildingYesWhich building to break: market / barracks / watchtower / walls / castle
Behavior5/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 extensively details outcomes: building tier drop, wall-first destruction, partial success as wall chip, failure with no effect, army loss in all cases, no defender window, newbie shield, NAP partner effects, ally betrayal penalties, and the grievance/justified war mechanic. This is thorough and transparent.

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

Conciseness1/5

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

The description is a verbose wall of text, repeating the same mechanical points multiple times (e.g., success/partial/failure outcomes are stated twice, and the defense modifier conditions are enumerated in near-duplicate clauses). It is far from concise and would benefit from significant trimming.

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?

The description is exceptionally complete for a combat action with no output schema: it covers success, partial, and failure states, unit losses, siege behavior on walled tiles, defender absence, kingdom modifiers (newbie shield, NAP, ally), and the diplomatic consequence (justified war). An agent has nearly all the context needed to decide and execute.

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 schema covers all 6 parameters with descriptions (100% coverage), so baseline is 3. The description adds meaningful context beyond the schema, such as 'commit at least the raid minimum' tying to committed_army and clarifying that plan_claims influence the multiplier. This extra nuance justifies a 4.

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 specific verb ('RAID'), a specific resource (enemy territory), and a specific objective (break a named building). It distinguishes itself from siblings by noting 'no war declaration needed' and 'never takes land', effectively separating it from declare_war and claim_territory.

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 clear situational context: raids are for breaking buildings without declaring war and without taking land. It also mentions cooldowns reference 'GET /api/v1/rules' and that a defender window does not exist. However, it does not explicitly name alternative tools or state 'use this instead of X', so it falls short of exhaustive guidance.

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

Install Server

Other Tools

Latest Blog Posts

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/playcrowns/crowns-mcp'

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