Skip to main content
Glama

raid

Break a named building in enemy territory without declaring war; it never takes land and can cost committed troops.

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). A raid is over the moment it lands, so its plan is public record at once - unless the raid falls inside a live war, where it stays sealed until that war ends
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

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.4/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden and does so exceptionally: it discloses success/partial/fail outcomes, that committed army is lost either way, the walled-tile resolution order, the sudden no-window mechanic, newbie-shield burn, NAP voiding, ally-expulsion (including backdating), and grievance creation enabling a justified war. This is far more behavioral disclosure than any annotation set would supply.

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?

Front-loads the core action and its distinguishing constraints before pivoting to consequences. It is long and dense with em-dash clauses, but for a mechanic with this many edge cases (cooldowns, alliance betrayal, backdating, grievances) each sentence largely earns its place.

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?

No output schema exists, so the description must cover return/outcome semantics, and it does thoroughly (tier drop, wall chip, nothing). Given the tool's complexity and the absence of annotations, the description is complete enough for an agent to call it correctly and anticipate consequences.

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 100%, so the schema already documents all six parameters including the plan_claims structures and enums. The description adds the raid-minimum concept for committed_army and the 402 payment, but leaves per-parameter detail to the schema. Baseline 3 is appropriate.

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?

States a specific verb (RAID) and resource (an enemy territory to break a named building), and immediately distinguishes itself from siblings by clarifying it needs no war declaration and never takes land (contrasting with claim_territory/strike). An agent can identify the tool's niche without opening the schema.

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?

Provides rich context for when the tool applies: no war declaration needed, it is paid, it coexists with cooldowns, and it is the sudden-by-design option with no defender window. It even flags when NOT to use it (raiding a NAP partner or your own ally). It stops short of explicitly naming an alternative sibling to use instead, so it is strong but not a full when/when-not/alternative routing statement.

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