Skip to main content
Glama
ty-meador

civ-v-llm-harness

by ty-meador
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

order

Destructive

Executes state-changing Civilization V actions for owned units, cities, empires, diplomacy, and spies, returning changed state or a specific refusal when a move is invalid.

Instructions

An order to something I own: to the target kind, id which one, action the verb, args its arguments by name. It changes the game, and most of it cannot be undone (a disbanded unit, a declared war, a purchase). Not a read: inspect shows the state and hands back the rows, question / answer settle what a popup asks, turn(action='finish') ends the turn. to: actions -- unit: move, mission, promote, upgrade, disband, trade_route, plunder city: produce, purchase, dequeue, sell_building, buy_plot, specialist, work_plot, governor, status, strike, great_work empire: research, policy, ideology, switch_ideology, pantheon, religion, enhance_religion, reformation, faith_purchase civ: propose_deal, negotiate, peace, demand, friendship, declare_war, denounce, event city_state: gift_gold, gift_unit, gift_improvement (or a city-state screen button by its name: pledge, revoke_pledge, bully_gold, bully_unit, declare_war, make_peace) league: propose, repeal, vote spy: move, coup How: copy the rows a read hands back (actions, call) as they are; id is a unit, city, civ, city-state or spy id (empire and league take none); args holds what the row holds (a plot's x and y, an item's name, a deal's items, an amount). An order runs whole or not at all. action_id: a token of mine; a retry with the same one replays the stored reply instead of acting twice. Returns {ok: true, ...} with what changed (a unit's new plot and moves left, a city's queue, a deal's answer), or {ok: false, err, choices / accepts, example}: the verb is not one of the target's (choices lists them), an argument is missing (accepts names the shape, example a complete call), or the game refuses it (err names the rule, e.g. the unit has no moves, the city is not mine, another client of my seat holds this turn's claim). Nothing is acted on when ok is false.

Input Schema

NameRequiredDescriptionDefault
idNowhich unit, city, civ, city-state or spy; empire and league take none
toYesthe target kind, something I own
argsNothe action's arguments by name, as the copied row has them; a refusal shows the shape with an example
actionYesthe verb, by target -- unit: move, mission, promote, upgrade, disband, trade_route, plunder; city: produce, purchase, dequeue, sell_building, buy_plot, specialist, work_plot, governor, status, strike, great_work; empire: research, policy, ideology, switch_ideology, pantheon, religion, enhance_religion, reformation, faith_purchase; civ: propose_deal, negotiate, peace, demand, friendship, declare_war, denounce, event; city_state: gift_gold, gift_unit, gift_improvement, or a city-state screen button by its name (pledge, revoke_pledge, bully_gold, bully_unit, declare_war, make_peace); league: propose, repeal, vote; spy: move, coup
action_idNoa token of my choosing: a retry with the same action_id replays the stored result instead of acting twice

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv2.1.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare destructive=true and readOnly=false, and the description adds substantial context beyond them: most orders cannot be undone, the operation is all-or-nothing, action_id replays stored replies on retry, and nothing is acted on when ok is false. It also enumerates the failure modes (bad verb, missing argument, game refusal) and what the response contains.

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?

The description is well organized and front-loads the mutation warning and the not-a-read distinction. It loses a point because the long target-to-action enumeration duplicates the action parameter's schema description almost verbatim, adding bulk rather than new information.

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, destructive, multi-target tool with no output schema, the description covers inputs, workflow, success/failure returns, error fields, and retry semantics. An agent has enough information to call it correctly and recover from failures.

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 100%, so the schema carries most parameter documentation. The description still adds practical semantics not captured there, especially the 'copy the rows a read hands back' pattern and concrete arg examples like a plot's x/y, an item's name, a deal's items, and an amount.

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 ('An order to something I own') and immediately decomposes it into to/id/action/args. It explicitly distinguishes itself from inspect, question/answer, and turn, so an agent can tell it apart from every relevant sibling.

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 'Not a read' and routes the agent to inspect for state, question/answer for popups, and turn(action='finish') to end the turn. It also explains the intended workflow: copy the rows a read hands back and pass them as they are.

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