Civ6 MCP CN

Overview Schema Source Related Servers Discussions Admin

set_production_queue

Plan a city's build order and automatically advance production when the slot is empty, preventing cities from idling after each completion.

Instructions

Plan a city's build order once — end_turn auto-advances it when the city's production slot is empty (defect 65: cities idling on "Building: nothing" for turns after every completion).

Args:
    city_id: City ID (from get_cities output)
    items: Comma-separated item names in order. item_type is inferred
           from the prefix (BUILDING_/UNIT_/DISTRICT_/PROJECT_).
           Districts MUST carry placement coords inline:
           "DISTRICT_CAMPUS@69,47" (use get_district_advisor first).
           **Wonders need coords too** — they are BUILDING_ items but
           are placed on a tile like districts:
           "BUILDING_FORBIDDEN_CITY@67,49" (use get_wonder_advisor).
           A wonder queued without coords cannot be rejected here (the
           prefix doesn't say which buildings are wonders) and fails at
           consumption time instead — 2026-08-11 T269 cost Ostia a whole
           idle turn that way.
           Example: "BUILDING_MARKET,UNIT_TRADER,DISTRICT_CAMPUS@69,47"
           Empty string shows this city's current queue.
           "clear" empties this city's queue.

The queue is a fallback, not a lock: a manual set_city_production always
wins; consumption happens only when the slot is empty at end_turn time.
A rejected item pauses the queue with a visible event — this includes
the RED-alert civilian-production gate, which still applies at
consumption time. Persisted per game — survives restarts.

Input Schema

Name	Required	Description	Default
`items`	No
`city_id`	Yes

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 23, 2026

TDQS

A4.9/5.0

Behavior5/5

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

With no annotations present, the description carries the full burden and does so: it discloses consumption timing, that a rejected item pauses the queue with a visible event, that the RED-alert civilian-production gate still applies at consumption time, and that state is persisted per game and survives restarts. It even flags a silent failure mode (a wonder queued without coords cannot be rejected up front and fails at consumption) with a concrete incident, which is unusually high-value 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Core purpose and the fallback semantics are front-loaded, and the arg block is scannable. A few passages drift into narrative (defect 65, the 2026-08-11 T269 Ostia anecdote) that could be tightened, though each does encode a real failure mode rather than pure filler.

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 two-parameter mutation tool with no annotations, the description covers purpose, argument encoding, precedence versus manual production, rejection/pause behavior, and persistence. An output schema exists, so return values need not be explained, and nothing an agent needs in order to call this correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate entirely, and it does: city_id is sourced to get_cities output, and items is fully specified with comma-separated ordering, prefix-based item_type inference, the 'DISTRICT_X@x,y' and 'BUILDING_X@x,y' coord syntax, a worked example, and the empty-string/'clear' special values. Nothing about either parameter is left to inference.

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 ('Plan a city's build order') and immediately clarifies the mechanism ('end_turn auto-advances it when the city's production slot is empty'). It also implicitly separates itself from the sibling set_city_production by declaring the queue a fallback rather than a lock, so an agent can distinguish the two without opening either schema.

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 names the competing tool and the precedence rule ('a manual set_city_production always wins; consumption happens only when the slot is empty at end_turn time'), which is exactly the when-to-use-vs-alternative guidance needed. It also gives precondition routing ('use get_district_advisor first', 'use get_wonder_advisor') and documents the two special modes (empty string = show current queue, 'clear' = empty it).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server