Skip to main content
Glama
Sign In
Civ6 MCP CN

Civ6 MCP CN

by 2962348318-del
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

purchase_item

Buy a city unit or building instantly with gold or faith, with an upkeep gate that blocks purchases pushing military spending past 60% of gross income.

Instructions

Purchase a unit or building instantly with gold or faith.

Args:
    city_id: City ID (from get_cities output)
    item_type: UNIT or BUILDING
    item_name: e.g. UNIT_WARRIOR, BUILDING_MONUMENT
    yield_type: YIELD_GOLD (default) or YIELD_FAITH
    force: Override the upkeep gate (UPKEEP_CEILING). Buying a unit is
    force_reason: One sentence on WHY you are overriding. Recorded to
        data/force_log.jsonl. Without it a post-game review cannot tell
        a wrong gate from a wrong call — write it even when in a hurry.
           blocked when it would push military upkeep past 60% of gross
           income — the purchase feels free, the bill arrives next turn.

Costs gold/faith immediately. Use get_city_production to see what's available.

Input Schema

NameRequiredDescriptionDefault
forceNo
city_idYes
item_nameYes
item_typeYes
yield_typeNoYIELD_GOLD
force_reasonNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.6/5.0
Behavior5/5

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

No annotations exist, and the description carries the full load well: it discloses immediate cost, the hidden UPKEEP_CEILING gate that silently blocks unit purchases, why the purchase 'feels free but the bill arrives next turn,' and the force_log.jsonl side effect of overriding. This is exactly the non-obvious behavioral context an agent needs before a spend.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

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

The purpose sentence is front-loaded and every fact earns its place, but the Args block is mangled: the 'force' explanation, the upkeep-gate rule, and the force_reason rationale are interleaved mid-sentence, forcing the reader to reassemble three paragraphs. The content is high-value but the structure fights comprehension.

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?

An output schema exists so return values need no explanation, and the description covers all six parameters, the gating rule, the cost timing, the logging side effect, and the discovery path to valid item names. Nothing an agent needs to invoke 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, and it does: it names every one of the six parameters, gives concrete enum examples (UNIT_WARRIOR, BUILDING_MONUMENT, YIELD_GOLD/YIELD_FAITH), states the default, and traces city_id back to get_cities output. enum values and defaults appear nowhere in the schema.

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 (purchase), resource (unit or building), and payment currency (gold or faith), and the word 'instantly' distinguishes it from queued production via set_city_production. An agent can tell this apart from purchase_tile and the set_*_production siblings without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Points the agent to get_city_production to see what's available and explains the force-override path with its condition (military upkeep past 60% of gross income). It gives clear context but never states when not to purchase at all, e.g. low treasury behavior.

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