Statesman MCP Server

list_cities

List and filter strategic urban power centers by keyword, theme, country, continent, or embedding status to locate cities for comparative geopolitical analysis.

Instructions

List and filter strategic urban power centers with civic/economic themes and embedding metadata.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

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

Input Schema

Name	Required	Description
`q`	No	Keyword search across city name, description, or country name
`limit`	No	Pagination limit (default: 50)
`theme`	No	Filter cities containing thematic tag (e.g. 'deepwater port', 'financial hub')
`offset`	No	Pagination offset (default: 0)
`embedded`	No	Filter by whether vector embedding has been generated
`country_id`	No	Filter by sovereign country ID
`continent_id`	No	Filter by continent ID
`include_embedding`	No	Include raw 1024-float vector array

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Nov 13, 2026

TDQS

C2.6/5.0

Behavior2/5

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

No annotations are supplied, so the description carries the full behavioral burden, yet it never states that this is a read-only operation, that results are paginated with defaults, or that include_embedding can return large 1024-float vectors. 'Embedding metadata' hints at return content but is not elaborated.

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, though the jargon ('strategic urban power centers') costs clarity that brevity alone does not recover.

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 an eight-parameter list tool with no annotations and no output schema, the description should clarify read-only semantics, pagination behavior, and the cost of requesting raw embedding vectors. It covers none of these, leaving the most consequential invocation details unaddressed.

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 the schema already documents all eight parameters including defaults and bounds. The description's 'civic/economic themes' and 'embedding metadata' phrasing loosely echoes the theme and embedding filters but adds no syntax or semantics the schema lacks.

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

Purpose3/5

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

The verb pair 'List and filter' is specific, but the resource is described only obliquely as 'strategic urban power centers' rather than as cities, so the agent must lean on the tool name to confirm what entity is returned. It gives no differentiation from siblings such as get_city or list_countries.

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 statement of when to use this list/filter tool versus get_city for a single record, or versus the country/continent listers for related entities. No prerequisites, exclusions, or alternative routes are named.

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

Deploy Server