Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault

No arguments

Instructions

Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.

This server publishes no instructions, or was last inspected before Glama recorded them.

Capabilities

Features and capabilities supported by this server

Protocol revision2025-11-25

CapabilityDetails
tools
{
  "listChanged": false
}
prompts
{
  "listChanged": false
}
resources
{
  "subscribe": false,
  "listChanged": false
}
experimental
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
referenceA

What things do, in two books. book="rules" (the default): the rule book of this very game, read once from its database (mods and DLC included) and cached -- every unit, building, wonder, project, process, promotion, social policy and ideology tenet, technology, belief, resource, terrain, feature, improvement, specialist and unit action, with its numbers. book="playbook": how to play through these tools (the turn loop, batches, blockers, diplomacy, the house rules, the action table). Read-only, usable while it is not my turn. Use it to learn what a choice means; use state for the live numbers (its chooser rows carry only the enum, the name and live numbers, never this text) and question for what a popup asks. section: one part per call. Rules sections: terrain, resources, improvements, units, buildings, projects, processes, promotions, policies, techs, beliefs, specialists, actions; left out, the whole book (tens of thousands of tokens: read it once at the start of a game if you can hold it, else the section a choice needs). Playbook topics: start, turn_loop, quiet_turns, batches, verify, blockers, diplomacy, rules, first_turn, orders (the action table), all; left out, the index of topics with the start section; city_state(s), deals, trade and league answer with diplomacy. Returns Markdown. An unknown rules section is refused as {ok: false, err, sections}; an unknown playbook topic answers with the topic list. Also served as the MCP resources civ5://reference and civ5://reference/{section}.

turnA

The clock: my seat's turn loop, one action per call. Actions: status -- whose turn it is, the gate (answer it before anything else), what blocks the end. Read-only. briefing -- my turn in one read: decisions with their actions rows, changes, board, threats, notes. finish -- run actions as a batch, end my turn, wait until it is mine again, return the new turn. end -- end the turn only, no wait. wait -- block until it is my turn again. Arguments by action: since, limit and detail belong to briefing (since='turn' after a context reset; detail='digest' is the event digest alone); actions and notes to finish; timeout_seconds to finish and wait; args (skip_quiet_turns, wake_on, autosave, force, briefing) to finish and end. Side effects: finish and end hand the game to the other players, and nothing they do can be undone -- order and answer everything first; a session save is the way back. finish autosaves to the quick-save slot. A refused row in actions stops the batch and the turn is not ended. Safe to repeat: when it is not my turn, finish only waits. A second client of my seat is refused with turn_claim (args.force takes the turn over). Timeouts: past timeout_seconds (600 by default) the reply says my_turn false, timed_out true and next is the call that resumes the wait; progress notifications go out every 5 s meanwhile, so one long call beats several short ones. Not this tool: question / answer for what the game asks (nothing ends while gate is set); state for the board; batch for orders that leave the turn open; session for saves. Returns: turn, my_turn, gate, todo / decisions, digest (what happened meanwhile), notes; game_over with victory / defeat at the end. A refusal is {ok: false, err, end_turn: {todo, skip_actions}}: what blocks the turn and the rows that clear it.

stateA

Read the game as my seat sees it: the empire, units, cities, civs and city-states, the map, the league, spies, the screens, and the choices open to me (research, policies, beliefs, trade routes). Read-only, no side effect, usable while it is not my turn. Use it before an order (its rows ARE the orders) and after one to verify; use reference for what things do, question for what a popup asks, turn for the turn's own state. How to call: what names the object, view the part of it (left out: the default view), id the one object. Objects and their views: empire: default, demographics notifications: default screen: tech_tree, religion, culture, culture_works, great_people, domination, spaceship, wonders, intrigue, trade_routes, deals league: default spies: default units: default, actions unit: actions, targets, tactical, home cities: default city: screen, production, strikes map: window, grid, index, frontier civs: default civ: summary, war, trade_catalog city_state: summary, full options: research, policies, beliefs, trade_routes, spy_cities compare: default Selectors, by view: x, y, radius for map/window and map/grid; radius alone for unit/tactical (centred on the unit); id for map/frontier (the explorer) and options/trade_routes (the caravan); mission for unit/targets; kind for options/beliefs and compare; detail ('summary' / 'full') where a view has both; since and limit for lists; item and yield_type for city/production to price one item; args for the rest by the old call's name. Returns: the object as JSON (a list for units, cities, civs; one dict otherwise), with actions or call rows wherever something can be done: each row is a complete order() call to copy. A wrong what or view is refused with choices, and for an object that takes an id, a hint saying where the ids come from (unit ids from units, city-state ids from the minor: true rows of civs). Replies are the 1.x reads' replies unchanged.

orderA

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: state shows the board 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.

questionA

What the game is asking right now, so answer() can settle it. Read-only; takes nothing. Use it whenever a reply's gate is not null or turn(action='status') says discussion_pending; use state for the board and reference for the rules. It shows one of: a decision popup (a tech, a production item, a policy, a promotion, a belief, a ruins reward, a captured city's fate, a Great Person's use, a dig), the leader on screen with their words and the deal on the table, another human seat's proposal waiting on the trade table, or nothing pending. Returns the popup's own read -- the question in words plus answers rows, each a complete answer() call to copy (the item's name or button number, and the args the popup needs) -- with gate on the reply; a leader screen returns the leader, the speech, the buttons and the deal's items; when nothing is asked, {pending: false, decisions: [...]} lists the turn's open decisions instead. Several leaders can queue at a turn start: answering one returns the next under next.

answerA

Answer what the game is asking: settle the one popup, leader screen or deal that question() shows, and nothing else. choice is the answers row's choice: an item's name (a TECH_, UNIT_, BUILDING_, POLICY_, PROMOTION_, BELIEF_ or goody name; liberate / annex / puppet / raze; a dig's choice number), a popup's or leader screen's button number, or on a leader screen accept / refuse (the deal on the table), leave (close it), accept_friendship. args carries the rest the popup needs (a promotion's unit_id, a dig's x and y, a stolen tech's player_id, a religion's beliefs and city). Dispatches on the gate: question() shows which question is up and hands back the rows to copy. It acts on the game as the popup's own button would -- an accepted deal, a razed city, a chosen tech cannot be taken back; a choice the popup does not offer, or an answer when nothing is asked, is refused with {ok: false, err, choices} and nothing happens. action_id: a retry with the same token replays the stored reply instead of answering twice. Not this tool: a decision with no popup up (research, production, a policy) is order; what a choice means is reference. Returns {ok, ...} with the popup's outcome and the gate that follows (still_pending and next when another leader waits; next also names the call that resumes the AIs' round when they are still moving), or the refusal.

notebookA

My memory, kept beside the game per seat and surviving a context reset or a restart: free-text notes, assignments (what a unit or city is for) and standing orders (a unit's plan the harness carries out over the coming turns). Use it for what future-me must know; the game itself holds no plan. Notes and assignments move nothing; a standing order does: give_order and resume_order run its first steps NOW (a move spends this turn's movement, a build starts) and carry on at the start of each of my turns. action, with its args -- remember {text, tag?, replace_id?}: write a note (returns it with its id; new notes ride on the next briefing / finish); recall {tag?, limit?}: list notes; forget {note_id}: delete a note for good. assign {role, purpose, unit_ids? / city_ids?}: give units or cities a purpose that shows in their state rows; assignments: list them; amend {assignment_id, purpose? / role?}; close {assignment_id}. give_order {unit_id, steps, interrupt?, purpose?, replace_id?}: steps is a list of at most 6, in order -- {kind: 'move', x, y}, {kind: 'build', build: 'FARM'}, {kind: 'heal', hp: 80}, {kind: 'hold', mission: 'fortify' | 'sleep' | 'alert'} (last) -- each step runs at most once per turn and the next starts as soon as one completes (a move that arrives starts its build the same turn); it never attacks, declares war or ends the turn, and pauses with a reason when a hostile comes near, the unit is hurt or a step is refused; one open order per unit (replace_id replaces it). orders: the plans with their status; cancel_order / resume_order {order_id}. Not this tool: a one-off move is order(to='unit'); a popup is answer; the board is state. Usable while it is not my turn. Returns {ok: true, ...} with the row written or the rows listed, or {ok: false, err, accepts, example} (an unknown action or a missing argument; nothing is written). A note written on a turn later than the one on screen (a save was loaded) comes back marked later_timeline.

batchA

Many orders in one call, in order, with the turn left open: actions is a list of {tool, args} rows -- the rows every read hands back (actions, call): order, answer and notebook rows alike -- each run as that call and answered under results. The first refusal stops the rest by default, since the state the later rows were reasoned about is no longer certain (stop_on_refusal=false runs them all); the rows not run come back under skipped. force=true takes over this turn's claim when another client of my seat holds it (otherwise the first row is refused with turn_claim). Not inside: the turn's wait / finish / end, a load, the seat, the exit, a batch. Each row changes the game as its order would and cannot be undone; a row's own action_id replays. Use it for several orders already decided; use order for one, and turn(action='finish', actions=[...]) when the same rows should end the turn afterwards. Returns {ok, done, results: [one reply per row], skipped?, hint?}: ok is false when any row was refused.

sessionA

Saves, loads and the seat of this game session: keep a state before a risky turn, open another save, leave a finished game, say which hotseat seat this server plays. It never plays a turn; use turn for that. Side effects: a load replaces the game on screen for everyone on it, and a hotseat game loads paused until turn(action='wait'); the notebook is per game and seat, so it follows a save of the same game and is not touched by a load. action -- save: a quick save of the game on screen into the one quick-save slot (each finished turn's autosave overwrites that slot, so copy a save you want kept); load {filename}: open that save (a name as the game lists it, without the single/ prefix; the refusal lists the legal ones), replacing the unsaved state, so save first; load_latest: open the newest save, whichever game it is; main_menu: leave the game for the main menu (the game_over gate's way out); seat {seat}: which human seat (0 or 1) this server plays in a hotseat game -- a server pinned with --seat refuses a change onto the other human seat, and never move onto the seat on screen. Returns {ok: true, saved / loaded, turn, seat, screen} or {ok: false, err} naming why (an unknown filename with the list, a seat that is someone else's, a game operation already running). In a game with other people ask the human before loading.

Prompts

Interactive templates invoked by user choice

NameDescription
play_turnPlay one turn of Civilization V through the civ5 tools.

Resources

Contextual data attached and managed by the client

NameDescription
referenceThe rule book: what every unit, building, tech, policy, promotion, belief, resource, terrain, improvement and unit action does, from this game's database. Markdown.
playbookHow to play through this harness: the turn loop, the blocker table, verification habits.

TDQS

A4.6/5.0

Scored across 9 tools

Disambiguation5/5

Each tool owns a distinct slice of the loop: order (single mutation), answer (popup settlement), state/reference/question (three different reads), turn (clock), batch (multi-order), notebook (memory), session (saves/seat). The descriptions go further than most servers by including explicit "Not this tool" sections (e.g. order vs batch vs turn(finish), answer vs order) so the nearest-neighbour confusions are pre-empted.

Naming Consistency4/5

All nine names are single lowercase words with no prefixes, suffixes, casing or separator mixing (order, answer, batch, session...), which is highly predictable. The only weakness is that they are bare nouns rather than verb_noun, so a few (state, notebook, reference) don't self-describe their action as immediately as a verb would.

Tool Count5/5

Nine tools for a game harness spanning mutation, reads, popup resolution, turn management, batching, persistence and session control is tight and every tool has a clear distinct job. Complexity is pushed into per-tool `action`/`what` sub-selectors rather than into more top-level tools, which is the right trade-off here.

Completeness4/5

The lifecycle is essentially covered: read board/rules/prompts, issue orders singly or batched, settle every popup, advance/wait the turn, keep notes and standing orders, save/load/seat. The one plausible gap is that session only saves, loads and reassigns seats — there is no operation for starting a new game, which a full session lifecycle would normally include.

Maintenance

ActivityActive
ResponsivenessNo recent community issues