Skip to main content
Glama
ty-meador

civ-v-llm-harness

by ty-meador

give_order

Assign a unit a short sequence of steps (move, build, heal, hold) that the harness executes over subsequent turns, eliminating per-turn commands.

Instructions

Give one of my units a short sequence of steps the harness carries out over the coming turns, so a plan already chosen does not cost a call every turn. steps (at most 6, in order): {kind: "move", x, y} walk there (multi-turn); {kind: "build", build: "FARM"} build it where the previous move ends (x, y name another plot); {kind: "heal", hp: 80} heal to at least that percent (default 100); {kind: "hold", mission: "fortify"|"sleep"|"alert"} as the last step. Example: move to (12,8) then build FARM; or heal to 80, move to (30,14), hold. purpose is a free-text label for the order. It runs now (start=true) as far as it can, then at the start of each of my turns (finish_turn / wait_for_my_turn carry orders), one step per turn at most, through move_unit / unit_mission. It pauses and hands the unit back with pause.reason and hint when a hostile comes into sight within interrupt.hostile_within plots (default 2; 0 off), the unit was damaged (interrupt.damaged, default true) or is below interrupt.hp_below, an enemy stands on the destination (an order never attacks), a step is refused or makes no progress, a save was loaded, or I give the unit a direct order. An order never declares war, attacks, ends the turn or touches another unit; a unit on automation leaves it as soon as the order is stored. One open order per unit (replace_id replaces it); a first step that cannot run now refuses the order. Stored in my notebook: orders survive a restart, briefing() lists them, resume_order / cancel_order finish a paused one. Every interrupt and state: how_to_play("give_order").

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
startNo
stepsYes
purposeNo
unit_idYes
interruptNo
replace_idNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.11.0

TDQS

A5/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 burden and does so thoroughly: it discloses interrupt triggers, pause.reason and hint behavior, that orders never attack/declare war/end turns/touch other units, automation removal, persistence across restarts, and one-order-per-unit semantics.

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

Conciseness5/5

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

The description is dense but front-loaded: purpose and execution model first, then step grammar, then interrupt and lifecycle details. For a complex multi-turn tool, every sentence adds needed operational information rather than repeating structured fields.

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?

Given no annotations, no output schema, six parameters, and 0% schema description coverage, the description is complete enough for correct invocation. It explains the lifecycle, return-side pause fields, persistence, and relevant sibling tools.

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 description coverage is 0%, so the description must compensate, and it does: it explains step kinds with examples and limits, start behavior, purpose as a free-text label, interrupt defaults, and replace_id. The main step object forms are fully specified, with only the string step variant left implicit.

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: give one unit a sequence of steps carried out over coming turns. It clearly distinguishes itself from immediate-action siblings like move_unit and unit_mission by describing the deferred, per-turn execution model.

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 says to use this when a plan is already chosen and should not cost a call every turn. It also covers replacement, refusal conditions, direct-order cancellation, and points to resume_order/cancel_order for paused orders.

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