Skip to main content
Glama
ty-meador

civ-v-llm-harness

by ty-meador
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

question

Read-onlyIdempotent

Reveals the pending in-game decision popup or leader dialogue, returning readable options plus ready-to-copy answers so the turn can move forward.

Instructions

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 inspect 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, 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.

Input Schema

NameRequiredDescriptionDefault

No arguments

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 readOnlyHint=true and idempotentHint=true, and the description adds substantive behavior beyond them: it lists the possible pending states and explains the different return shapes, including the leader queue and `next` chaining. This gives the agent a clear model of what calling it will produce.

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 front-loaded with the core purpose and trigger conditions, then details return shapes. It is somewhat dense and includes long parenthetical enumerations, but most of that content is relevant given the tool's conditional output behavior.

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?

There is no output schema, so the description must explain return values, and it does: popup answers, leader screens, and the nothing-pending case with `pending`/`decisions`, plus multi-leader chaining via `next`. It is complete enough for an agent to call and interpret this zero-parameter read tool confidently.

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?

The tool takes zero parameters, so the baseline is 4. The description reinforces this with 'takes nothing,' and schema coverage is 100%; there are no parameters whose semantics need further explanation.

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/resource: reads what the game is asking right now so answer() can settle it. It explicitly distinguishes siblings by directing board inspection to inspect and rules to reference, so an agent can separate this tool from alternatives.

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?

Gives explicit trigger conditions: use whenever a reply's `gate` is not null or turn(action='status') says discussion_pending. It also names the correct alternatives for adjacent needs (inspect for the board, reference for rules).

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