Skip to main content
Glama
Sign In
civ-v-llm-harness

civ-v-llm-harness

by ty-meador
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

reference

Read-onlyIdempotent

Look up Civilization V rule details or playbook guidance by section to understand what a game choice means before acting.

Instructions

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}.

Input Schema

NameRequiredDescriptionDefault
bookNo'rules' (default): what everything in this game does; 'playbook': how to play through these toolsrules
findNorules: keep only the headings and the lines containing this word (a section too long for one reply: promotions, buildings)
sectionNoone section: a rule-book heading (terrain, units, buildings, ...) or a playbook topic; left out, the book's index

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv2.7.0
    • addedInput schema / properties / find
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "rules: keep only the headings and the lines containing this word (a section too long for one reply: promotions, buildings)",
+  "title": "Find"
+}
  2. Changed2 schema fields changedv2.1.0
    • addedInput schema / properties / book
      Added value: +{
+  "default": "rules",
+  "description": "'rules' (default): what everything in this game does; 'playbook': how to play through these tools",
+  "title": "Book",
+  "type": "string"
+}
    • addedInput schema / properties / section / description
      Added value: +"one section: a rule-book heading (terrain, units, buildings, ...) or a playbook topic; left out, the book's index"
  3. First observedv1.11.0

TDQS

A4.6/5.0
Behavior4/5

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

Adds substantial context beyond annotations: rules are read from the game database including mods and DLC and cached, full-book reads are tens of thousands of tokens, unknown sections are refused with an error structure, and results are Markdown. Annotations already cover read-only and idempotent behavior, but the description still adds useful operational details.

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?

Information is front-loaded with the two-book distinction followed by usage guidance and parameter behavior. It is dense and somewhat verbose with long parenthetical lists, so it is not maximally concise, but the complexity justifies most of its length.

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?

The tool has no output schema, and the description compensates by explaining return format, section/topic behavior, fallback indexes, error handling for unknown sections, and MCP resource equivalents. It provides everything needed to invoke a complex reference 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 100%, so the baseline is 3. The description still adds value by listing concrete section names, explaining the default whole-book behavior and token cost, and clarifying how find narrows long sections such as promotions and buildings.

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 resource: two reference books, rules and playbook, and enumerates what each covers. It clearly distinguishes this documentation lookup from sibling tools like state and question, which provide live data or popup prompts.

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 to use reference to learn what a choice means, while directing live numbers to state and popup wording to question. It also notes the tool is usable when it is not the agent's turn, giving clear context for when to call it.

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