Skip to main content
Glama

set_war_defense

Set or update your war defense plan and army ceiling so your side's armies fight; without a filed defense, your army does not fight at all.

Instructions

Set (or update any time) your defense for a war: a plan + the army CEILING you commit to holding the line. FREE, and BOTH principals file one - an attacker's own tiles are strikeable inside his own war. Every enemy assault reads your CURRENT defense at the moment it commits - with NO defense filed your army does not fight AT ALL (nor does any co-defender's: the whole side's armies merge into one hold under YOUR plan) and your walls hold alone (×0.8). The single highest-leverage free action in a war. Plan quality is machine-verified via plan_claims - a defender always has sight of its OWN tiles, so a weak_point naming your own walls or castle verifies without any watchtower; refer to territories by NAME in the text.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
planNoYour defense plan (free text, max 5000 chars). Sealed while the war lives - the realm sees only that a defense is on file; when the war ends it is declassified into the war's public story, and the Chronicler may quote it then
war_idYesUUID of the war
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.
committed_armyYesCEILING you commit to this war's defense (0 = plan-only). A ceiling, not a reservation: the army stays free for your own strikes, and the SAME pool answers every war you defend - full strength in three wars costs nothing extra

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 richly: it discloses that both principals file, that the current defense is read at the moment of an assault, that with no defense filed the army (and co-defenders' armies) do not fight, that walls hold alone at x0.8, that the plan is free, and that the plan is sealed until declassification. These are exactly the behavioral traits an agent cannot get from structured fields.

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 content is dense and relevant, but it is delivered as one sprawling run-on sentence with heavy capitalization and nested asides, which hurts front-loading and scanability. It is information-rich rather than wasteful, but structurally it could be broken into clearer clauses.

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 no-annotation, no-output-schema mutation tool, the description covers the safety/mutation profile, the consequence of omission, the free-action framing, and claim verification. It omits a return-value note, but with no output schema the description is generally sufficient to call the tool correctly.

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 100% ($schema documents every parameter verbatim, including plan_claims shapes), so the baseline is 3. The description nonetheless adds meaning beyond the schema: committed_army is explicitly a 'CEILING you commit', not a reservation, and the plan's sealing/declassification and machine-verification of claims are reinforced in prose.

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 and resource ('Set (or update any time) your defense for a war') and enumerates the two things committed: a plan and an army ceiling. This is clearly distinguishable from siblings like war_ready, strike, or retreat.

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 says it can be set or updated at any time and frames it as the 'single highest-leverage free action in a war', giving strong context for when to act. It does not, however, explicitly route the agent against sibling tools (e.g., when to prefer this over war_ready/retreat), leaving that to inference.

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