Skip to main content
Glama
ty-meador

civ-v-llm-harness

by ty-meador

tactical_view

Read a unit's surroundings—adjacent plots, terrain, visible occupants, cities, and melee/ranged targets with previews—to choose its next move or attack.

Instructions

One unit's surroundings in one read, for choosing its move or attack. neighbors are the six adjacent plots by coordinate and direction (NE, E, SE, SW, W, NW; the engine's own adjacency, so map wrap and the edge rows need no hex arithmetic), each with terrain, river_crossing, owner, visible units and move: attack (a melee attack; its preview is in targets), open (move_unit would send the order), refused (move_unit would refuse it, why says why) or enemy (a visible enemy this unit cannot melee). open is not a path cost: turns-to-reach and movement cost are not available. targets are the unit's melee and ranged targets with the combat previews available_unit_actions gives. occupants (visible units, hostile first) and cities (a fogged one is last_seen) cover radius (1-5; by default as far as this unit itself sees or shoots, at least 2); fog counts visible, fogged and unrevealed plots there, and unseen_within_2 is how many plots within two cannot be seen: fog can hide units, so nothing is called safe. unit.sight is this unit's own line of sight from the engine (range, on_hills, plots, reach: high ground adds a plot, hills and forest in between block); a ranged unit's unit.fire_los is the same test with its attack range, the one a ranged attack must pass (a Crossbowman on a hill reaches 3); occupant and city rows say in_sight / in_fire_los. grid is a lettered picture of the same area with its legend; players names every owner id in the reply. detail="full" adds plots (every revealed plot in radius, as map_window reads it) and the previews' modifier rows.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
detailNosummary
radiusNo
unit_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.11.0

TDQS

A4/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 richly: it defines every `move` value, warns that `open` is not a path cost, explains fog counting, states nothing is called safe because fog hides units, and details the LOS/fire_los tests. This is unusually thorough behavioral disclosure.

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 content is dense and largely fluff-free, but it is delivered as one enormous paragraph mixing purpose, return semantics, and parameter docs. It is hard to scan, and some detail (grid/legend, players) could be tightened.

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 complex, annotation-free, output-schema-less tool, the description covers all returned sections, their semantics, and parameter behavior. An agent has enough to interpret the reply and call the tool correctly.

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 0%, yet the description explains `radius` (range 1-5, default as far as the unit sees or shoots, at least 2) and `detail="full"` (adds plots and modifier rows) in depth. Only `unit_id` is left to the schema, but it is self-evident given the tool's framing.

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?

The opening states a specific verb and resource: showing one unit's surroundings for choosing a move or attack. It scopes the tool tightly (one unit, one read) and enumerates the returned sections. It never names a sibling (e.g. map_window, available_unit_actions) to differentiate against, so it falls short of a 5.

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

Usage Guidelines3/5

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

Usage is implied by 'for choosing its move or attack', and the text leans on siblings by reference ('previews available_unit_actions gives', 'as map_window reads it'). But there is no explicit when-to-use or when-not versus map_window/units, so the agent must infer routing.

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