Statesman MCP Server

populate_country_cities

Discover and generate 8–10 strategic cities for a specified country via LLM extraction, enabling urban catalog population from a country ID.

Instructions

Discover and generate 8-10 strategic cities for a country via LLM extraction.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "id": "<id>"
    },
    "name": "populate_country_cities"
  }
}

Input Schema

Name	Required	Description	Default
`id`	Yes	Country ID
`sync`	No	If true, wait synchronously for city discovery to complete

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Nov 13, 2026

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations, the description carries the full behavioral burden, and it discloses little: 'LLM extraction' hints at non-determinism but says nothing about persistence side effects, duplicate handling on re-run, cost/latency of an LLM call, or required permissions. The synchronous-wait behavior implied by the sync parameter is left entirely to the schema.

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?

A single front-loaded sentence with no filler, which is efficient. It is borderline under-specified rather than bloated, but nothing in it is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a generating, presumably mutating tool with zero annotation coverage and no output schema, the description should say what is written, what is returned, and how re-runs behave. None of that is present, so an agent could invoke it without knowing the side effects.

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

Parameters3/5

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

Schema description coverage is 100%, so both parameters (id, sync) are already documented in the schema and the baseline is 3. The description adds no meaning beyond that - neither the country id nor the sync/blocking semantics are elaborated in prose.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb pair ('discover and generate') and resource ('cities for a country'), plus a concrete quantity (8-10) and mechanism ('LLM extraction'). It falls short of 5 because it never distinguishes itself from near-siblings such as populate_cities_bulk, create_city, or populate_continent_countries, so an agent cannot tell which populate path to take from the description alone.

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

Usage Guidelines2/5

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

There is no guidance on when to use this versus bulk city tooling or per-city creation, and no prerequisites stated (e.g., whether the country must already exist or be fetched via get_country). The only implied usage is 'for a country', which an agent must infer.

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

Deploy Server