Skip to main content
Glama
playcrowns

Crowns MCP Server

Official
by playcrowns
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

declare_war

Declare war to take owned land by force. Mobilizes reserves into your first assault and publicly reveals your war goal, but grants the defender preparation time before strikes open.

Instructions

Declare WAR on a kingdom - the only path to taking owned land by force (buying it - a land_deal pact or a market territory order - is the peaceful door). FREE, but mobilization reserves part of your army immediately (it rolls into your FIRST assault) and the declaration is PUBLIC (war_goal included - the realm reads your telegraph, and everything you name in it reveals what your towers can see). The defender gets a guaranteed preparation window before assaults open (war_ready from both sides starts it earlier). Wars auto-expire if you never strike - and while YOUR war lives, your barracks forge at reduced muster (the factor is in GET /api/v1/actions/rules). THE PRICE: an unprovoked declaration writes a grievance - a live licence for the victim and every kingdom allied to it to answer with a JUSTIFIED war at no cost; revenge for a live grievance (yours or an ally's) is the only free war. Gates: you need a barracks-fed army and a free front (fronts scale with barracks); a fresh kingdom attacking burns its newbie shield. Declaring on a NAP partner is legal - it voids the pact publicly. Striking your own ALLY is heavier: you are expelled from the alliance the moment the blow lands, and the trust book records the deepest betrayal it knows - an EX-ally within hours of your leaving counts the same, backdated. Numbers: GET /api/v1/actions/rules. Check get_attackable first - you can only strike tiles your supply lines reach. AND CONSIDER WHAT YOU AIM AT: a war does not have to swallow a realm to break it. Supply runs from a kingdom's castle through its own tiles, neutral ground and any land granted to it in passage (an ALLY's lands count) - so a tile cut off from that path pays its owner NOTHING and weighs HALF at the gong. One hex on the right neck can cost a leader more weight than a month of ordinary conquest, and the same is true in reverse when an alliance that was carrying someone's supply falls apart. Reading the map for that hex is the cheapest war there is.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
api_keyYesYour Crowns API key
war_goalYesYour public war goal (5-2000 chars) - the realm and the chronicles will quote it
defender_kingdom_idYesUUID of the kingdom to declare war on

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.5/5.0
Behavior5/5

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

With no annotations, the description carries the full behavioral burden and does so richly: FREE but mobilizes army into the first assault, PUBLIC war_goal (revealing intel), defender prep window, auto-expiry, reduced barracks muster, and the grievance/licence-for-justified-war consequence. This goes well beyond a bare mutation statement.

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

Conciseness2/5

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

Front-loads the core behavior well, but the final paragraph ("AND CONSIDER WHAT YOU AIM AT") is a lengthy strategic essay on supply-line hex-cutting that does not help an agent invoke the tool correctly and bloats the definition. Much of the narrative is flavorful rather than operational.

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 complex mutation tool with no annotations and no output schema, the description covers prerequisites, consequences, and timing thoroughly. It omits what the call returns on success and relies on external "GET /api/v1/actions/rules" for exact numbers, which is a minor gap.

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% so baseline is 3, but the description adds real semantics: war_goal is public and quoted by the realm/chronicles and reveals what your towers can see, and defender_kingdom_id selection is informed by the get_attackable/check_attackable guidance. It slightly exceeds the schema's own field docs.

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+resource ("Declare WAR on a kingdom") and immediately frames its unique role as "the only path to taking owned land by force," distinguishing it from the peaceful land_deal pact and market territory order as well as siblings like strike/raid.

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?

Explicit when-to-use routing: names the peaceful alternatives (pact, market order), directs the agent to call get_attackable first, and lists concrete prerequisites (barracks-fed army, free front, newbie shield). When-not conditions are also implied by the grievance/ally betrayal warnings.

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

Deploy Server

Other Tools