Skip to main content
Glama

unit_action

Command Civilization VI units to move, attack, fortify, improve tiles, or merge into corps/armies by supplying a unit ID and target details.

Instructions

Issue a command to a unit.

Args:
    unit_id: The unit's composite ID (from get_units output)
    force: Override a safety block. Only set this after reading the
        block's explanation and deciding the risk is worth it — the
        safety checks exist because these mistakes cost whole games
        (civilians walking into barbarians, ranged units moving before
        they shoot). Leave it False by default.
    force_reason: One sentence on WHY you are overriding. Recorded to
        data/force_log.jsonl. Without it a post-game review cannot tell
        a wrong gate from a wrong call — write it even when in a hurry.
    action: One of: move, attack, fortify, skip, found_city, improve, repair, remove_improvement, remove_feature, build_route, automate, heal, alert, sleep, delete, trade_route, activate, sacrifice_charges, hurry_production, hurry_wonder, hurry_district, teleport, spread_religion, excavate, form_corps, form_army, rebase
    target_x: Target X coordinate (required for move/attack/trade_route/teleport/rebase)
    target_y: Target Y coordinate (required for move/attack/trade_route/teleport/rebase)
    improvement: Improvement type for builders (required for improve), e.g.
        IMPROVEMENT_FARM, IMPROVEMENT_MINE, IMPROVEMENT_QUARRY,
        IMPROVEMENT_PLANTATION, IMPROVEMENT_CAMP, IMPROVEMENT_PASTURE,
        IMPROVEMENT_FISHING_BOATS, IMPROVEMENT_LUMBER_MILL

For move/attack: provide target_x and target_y.
For trade_route: provide target_x and target_y of destination city.
For teleport: provide target_x and target_y of destination city. Traders only, must be idle (not on active route).
For rebase: provide target_x/target_y of a friendly aerodrome or carrier. Air units only —
    they never use move (they don't walk the map), and anything past their 15-tile strike
    range can only be reached by rebasing. Long hops may be refused; go via an intermediate
    aerodrome (measured: 44 tiles rejected, 20 accepted).
For improve: provide improvement name. Builder must be on the tile.
For repair: repairs a pillaged improvement on the builder's current tile. No improvement name needed.
For remove_improvement: demolishes an intact improvement on the builder's current tile (e.g. to replace a farm with a mine). Costs one charge.
For activate: activates a Great Person on their matching district.
For sacrifice_charges: Royal Society builder sacrifice — spends ALL builder charges to boost a district project (2% of cost per charge). Builder must be on the district tile. Expansion-only; absent in RULESET_STANDARD.
For hurry_production: spends builder charges to hurry construction on the builder's current tile, auto-detecting which variant this civ has. hurry_wonder forces the wonder variant (Qin Shi Huang / FIRST_EMPEROR_TRAIT, early eras only), hurry_district forces the district variant (Aztec). Move the builder onto the in-progress wonder/district tile first. If your leader lacks the ability the error says so explicitly — it is a ruleset limit, not a tool failure.
For form_corps / form_army: merges the SAME-TYPE unit at target_x/target_y into this
    one. Corps (+10 combat strength) needs Nationalism; Army (+17) needs Mobilization —
    these are the two free power spikes on the civics tree, and the same standing army
    gains roughly an era's worth of strength by merging. Both units must be the same
    unit type; move them together first.
For spread_religion: spreads religion at current tile. Missionaries/Apostles only.
For build_route: builds road/railroad on current tile. Military Engineers only. No charges used; costs 1 Iron + 1 Coal per railroad tile.
For fortify/skip/found_city/automate/heal/alert/sleep/delete: no target needed.
heal = fortify until healed (auto-wake at full HP).
alert = sleep but auto-wake when enemy enters sight range.
delete = permanently disband the unit.

Input Schema

NameRequiredDescriptionDefault
forceNo
actionYes
unit_idYes
target_xNo
target_yNo
improvementNo
force_reasonNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.7/5.0
Behavior5/5

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

No annotations exist, so the description carries the full burden and does: it names irreversible operations ('delete = permanently disband'), resource costs (1 Iron + 1 Coal per railroad tile, one charge for remove_improvement, ALL charges for sacrifice_charges), the force-override safety gate, and the side effect of writing to data/force_log.jsonl. Error behavior is also characterized ('Long hops may be refused... 44 tiles rejected, 20 accepted'), which is unusually concrete.

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-loaded with the core purpose, then structured as an args block plus per-action rules, which is easy to scan. Some passages are padded with motivational prose ('these mistakes cost whole games (civilians walking into barbarians, ranged units moving before they shoot)'), but the density of actionable content remains high for a 27-action tool.

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?

For a 7-parameter, 27-action mutation tool with no annotations, the description covers every action's requirements, prerequisites, costs, and common failure modes, and an output schema exists so return values need no explanation. Nothing an agent needs in order to call this correctly appears to be missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must supply all parameter meaning and it does: unit_id provenance ('composite ID from get_units output'), the full 27-value action enum that the schema leaves as a bare string, conditional coordinate requirements, and concrete improvement identifiers (IMPROVEMENT_FARM, IMPROVEMENT_LUMBER_MILL) where the schema has only a nullable string. It fully compensates for the empty schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb+resource: 'Issue a command to a unit.' Combined with the exhaustive action list, an agent can immediately tell this is the mutation entry point for units versus sibling reads like get_units or get_unit_promotions. It stops short of naming a sibling to differentiate against, so 4 rather than 5.

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?

Explicitly routes each action: 'For move/attack: provide target_x and target_y', 'Air units only — they never use move', 'go via an intermediate aerodrome'. Prerequisites (techs, unit types, tiles occupied, idle status) and failure conditions (ruleset limits, long-hop refusal) are stated per action, so the agent knows both when to invoke each action and when an action is not applicable.

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