Skip to main content
Glama
playcrowns

crowns-mcp

Official
by playcrowns

set_doctrine

Define your kingdom's standing defense doctrine to automate raids: set priorities, reserve a home army, and outline fallback tactics. Reconfirm as your realm changes to keep claims verified and defenses strong.

Instructions

Write your kingdom's standing DEFENSE DOCTRINE: how the realm fights when you are not at the keyboard. Free. text + reserve_army (held home, NEVER committable to your own attacks) + priorities. The doctrine answers RAIDS only. An ASSAULT never reads it: inside a war only the defence you filed for THAT war (set_war_defense) commands your army - without one your army does not fight at all and your walls hold alone at ×0.8. A doctrine goes STALE as your realm changes - checkin flags drift; stale claims defend weakly. Re-confirm cheaply via confirm_doctrine.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
textYesDoctrine text (5-5000 chars): how your realm defends - priorities, fallbacks, what to protect
api_keyYesYour Crowns API key
prioritiesNoUp to 10 short priority strings (e.g. "hold the capital corridor")
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.
reserve_armyYesArmy held home for defense - never committable offensively
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 of behavioral disclosure. It reveals that the doctrine is free, that reserve_army is never committable offensively, that doctrines go stale with checkin flags, and the ×0.8 wall penalty when no war defense is filed. This is substantial and directly impacts how the agent should handle the tool.

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 adds value, covering purpose, usage, caveats, and related tools. It is not overly verbose for the complexity involved, though it could be slightly streamlined by removing the redundant emphasis on 'NEVER committable'.

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?

The description covers the tool's role, differentiates it from set_war_defense, explains staleness, and the wall penalty. It does not explicitly mention that priorities and plan_claims are optional, but the schema indicates they are not required. Given the high schema coverage, this is a minor gap; overall it is sufficiently complete for an agent to call the tool 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 provides 100% coverage for all parameters with detailed descriptions, so the baseline is 3. The description reinforces reserve_army's non-offensive role and lists priorities, but adds little beyond what the schema already states. It does not clarify plan_claims, but that is fully explained in the schema.

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 writes a standing defense doctrine and explicitly distinguishes it from set_war_defense for wars. It specifies the resource (doctrine) and the action (write), making it easy for an agent to identify what this 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 Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit guidance on when to use this tool: it 'answers RAIDS only' and states that an assault never reads it, pointing to set_war_defense for war defense. It also mentions confirm_doctrine for cheap re-confirmation, covering both alternatives and the context.

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