civ6-mcp

Overview Schema Source Related Servers Discussions Admin

get_revealed_map

Read-only

Retrieve the revealed map as a compact character grid with coordinates for visible cities and units, enabling spatial analysis and targeted actions.

Instructions

The whole revealed map as a compact character grid, plus entity positions.

One character per tile so the full map fits in a bounded amount of text —
spatial structure is preserved, fine detail is not. Rows are printed north to
south; column index is x.

Legend: ' ' unrevealed, '~' water, 'M' mountain, '^' hills, 'g' grassland,
'p' plains, 'd' desert, 't' tundra, 's' snow, 'F' forest, 'J' jungle,
'W' marsh/floodplain.

Cities and units follow with exact coordinates and owner ids, since those are
what orders reference. Only revealed tiles and visible units appear — this
never exceeds what the player can actually see.

KEPT DELIBERATELY, for the entity lists rather than for the grid. The
`cities:` section is the only place any tool reports FOREIGN cities with
coordinates — get_city_states names city-states without positions, and
get_diplomacy gives a per-civ city count and none at all — so it is what
anything needing a target city coordinate has to read (the jev harness's spy
travel options come from here). The grid is for computing facts from, not for
pasting into a prompt: a measured probe put an ASCII map of this shape in
front of a model and frontier identification was 2/21, chance, while the same
fact counted and stated in words was 21/21.

Not cheap: the map is scanned in five row bands because one whole-map Lua
pass overran the FireTuner read, so this is five round-trips. Callers that
want it every turn should cache it for the turn.

The `visible units:` rows have the SAME line shape as the `cities:` rows, so
any parser has to scope itself to the section header rather than matching
"(x,y) name [player n]" line by line.

Input Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.1.11Sep 19, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Beyond the readOnlyHint, the description discloses that only revealed tiles and visible units appear, so output never exceeds what the player can see. It also reveals operational behavior: the map is scanned in five row bands, making it expensive, and visible-units rows share the same line shape as cities, requiring parser scoping. This is substantial value beyond the annotation.

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 purpose, then legend, then usage and caveats, and every paragraph carries operational value. It is longer than typical but justified by the need to explain the legend, cost, and parser pitfalls; still, the 'KEPT DELIBERATELY' phrasing and probe anecdote make it slightly less crisp than ideal.

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?

Despite having an empty input schema and an output schema, the description supplies the contextual information an agent needs: character meanings, orientation, visibility constraints, cost, caching policy, and parsing hazards. It is complete for correct invocation and interpretation.

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?

There are no parameters, so the input schema is empty and there is nothing to define. The description instead clarifies what the returned grid and sections mean, aligning with the 0-parameter baseline of 4.

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?

The opening sentence states exactly what the tool returns: the whole revealed map as a compact character grid plus entity positions. It further differentiates itself by noting the cities section is the only source of foreign city coordinates, separating it from get_city_states and get_diplomacy.

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?

The description explicitly says when to use this tool — for entity lists, especially foreign city coordinates — and when not to: the grid should be used for computing facts, not pasted into a prompt. It also warns about the cost (five round-trips) and recommends caching per turn, which is actionable usage guidance.

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

Deploy Server