Skip to main content
Glama
ty-meador

civ-v-llm-harness

by ty-meador

todo_actions

Fetch legal actions for multiple units in one call, including promotions and targets, to replace individual per-unit queries.

Instructions

Legal actions for many units in one call. With no unit_ids: every unit in turn_status.todo.units (still needs an order) plus every unit with a promotion waiting; with unit_ids: exactly those. Each row is what available_unit_actions returns for that unit (actions, promotions, nearby_builds, attack_targets, ranged_targets, moves, x, y) plus id, type and promotion_ready. Action rows drop the computed help line (upgrade price, scrap gold) unless full=true; the standing text for every action and promotion is in reference("actions") / reference("promotions"). One query instead of one per unit: the read for a whole turn's units in one call. Refused while it is not our turn unless unit_ids is given. detail: "normal" (default, the rows above), "full" (same as full=true) or "summary": per unit only id, type, x, y, moves, promotion_ready, actions as bare type strings minus the everyday ones (move, route, swap, skip, sleep, fortify, alert, wake, cancel, delete, automate/stop, remove route -- listed once in routine_actions, counted per unit in routine), promotions (enums for choose_promotion), attack / ranged targets (x, y, unit or city, owner, hp; no preview) and build_plots (x, y, builds, resource). drill_down gives the exact todo_actions arguments for the normal rows. Same single read at every level; a summary of 38 units is a fraction of the normal size. limit returns the first N units in todo order and lists the rest in omitted (count, ids, the args that fetch them). Every reply has detail, n (total units) and returned.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
fullNo
limitNo
detailNo
unit_idsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.11.0

TDQS

A4.6/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 thoroughly: turn-gating/refusal behavior, what changes at each detail level, that action rows drop the computed help line unless full=true, and that limit truncates with an `omitted` payload. This is above-and-beyond disclosure of side effects, output shape, and constraints.

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 purpose is front-loaded and the content is dense rather than padded, but the prose is one long run-on of nested parentheticals that is hard to parse. For a 4-param tool the length is justified by the detail-level complexity, yet structure and scannability suffer.

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 a batch tool with three detail modes, no output schema, and 0% schema coverage, the description covers routing, gating, per-mode field lists, and truncation metadata. There is no output schema, yet the returned keys (detail, n, returned, omitted) are explained. Nothing an agent needs to call it correctly is 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 fully compensate, and it does: full (retains help lines), detail (normal/full/summary, with the semantics of each), unit_ids (exact selection vs all todo+promotion-ready units), and limit (first N in todo order plus `omitted` metadata). Each of the four parameters is given meaning beyond the bare schema names.

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?

Opens with a specific verb+resource: 'Legal actions for many units in one call.' It explicitly distinguishes itself from the sibling available_unit_actions by describing itself as the batched equivalent ('Each row is what available_unit_actions returns for that unit'). An agent can immediately tell this is the one-shot, whole-turn aggregate rather than the per-unit call.

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?

Gives concrete context for selection: the no-unit_ids vs unit_ids branch, the turn gating ('Refused while it is not our turn unless unit_ids is given'), and the efficiency rationale ('One query instead of one per unit'). It points to drill_down and reference for follow-ups. It stops short of an explicit when-not-to-use-this-and-use-X-instead statement, so not quite a 5.

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