Skip to main content
Glama
ty-meador

civ-v-llm-harness

by ty-meador

units

Get full details on your civilization's military and civilian assets—position, health, moves, promotions, XP, upgrade options, and orders needed—to plan your strategy.

Instructions

My units with position, moves left, hp, strength, current promotions, XP toward the next promotion (xp / xp_needed), and whether they still need orders. garrisoned is the Military Overview status. upgrade_to / upgrade_gold / can_upgrade are the unit-panel upgrade preview when a path exists; upgrade_blocked (when can_upgrade is false) is the panel's red lines: reason territory / city / gold / resources (each short one) / stacking, unavailable (the target cannot be trained yet: prereq_tech) or moved. A religious unit carries religion (the faith it spreads, which is the one of the city it was bought in -- not necessarily yours) and spreads_left, as the unit panel names it. A Worker mid-job carries build (BUILD_*) and build_turns_left as the unit panel's "Trading Post (6)" line; mission_name names a standing MISSION_* (e.g. ROUTE_TO). territory {player_id, owner, city_state} is whose land the unit stands on when it is not mine (a unit in a city-state's land costs influence each turn); absent on my own or unowned land.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.11.0

TDQS

B3.1/5.0
Behavior3/5

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

With no annotations, the description carries the full burden, and it does disclose meaningful semantics: 'territory' is absent on my own/unowned land and a unit in city-state land 'costs influence each turn', garrisoned maps to the Military Overview status, and religion 'not necessarily yours'. However it never characterizes the tool's own behavior as a safe read with no side effects, and only informally describes derived fields like can_upgrade/upgrade_blocked.

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?

For a tool with no output schema the field-by-field detail is justified, but it is delivered as an unstructured run-on of parentheticals with no headings or grouping. It also begins mid-thought ('My units with...') with no leading sentence stating what the call returns.

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?

No output schema exists, so the description must document the return payload, and it does so densely and largely coherently for every listed field (xp/xp_needed, upgrade preview, religion/spreads_left, build/build_turns_left, mission_name, territory). What is missing is the framing sentence that says what the tool actually returns as a whole and whether the result can be empty.

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?

Zero parameters, so there is nothing for the description to disambiguate; the baseline of 4 applies. The text instead spends its budget on output-field semantics, which is reasonable here.

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

Purpose3/5

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

The description never states a verb, but the opening 'My units with position, moves left, hp, strength...' makes the resource and the returned-record shape clear enough for an agent to infer a read of owned units. It offers no differentiation from unit-related siblings such as 'orders', 'available_unit_actions', or 'unit_mission_targets', leaving selection partly to inference.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

There is no when-to-use statement, no prerequisites, and no mention of alternatives, despite many sibling tools operating on units. An agent gets field semantics but no routing guidance at all.

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