Statesman MCP Server

generate_city_embedding

Computes a 1024-dimensional vector embedding for a city record by ID, enabling vector-based search, clustering, and counterpart discovery; optionally waits for completion.

Instructions

Calculate 1024-dimensional vector embedding for a city record.

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": "generate_city_embedding"
  }
}

Input Schema

Name	Required	Description	Default
`id`	Yes	City ID
`sync`	No	If true, wait synchronously for embedding generation to finish

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 burden but discloses nothing about side effects: whether an existing embedding is overwritten, whether the call is idempotent, whether it costs money or is rate limited. Most critically, it never explains what happens when sync=false, even though a get_job_status sibling suggests an async job workflow exists.

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

Conciseness5/5

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

A single front-loaded sentence with no filler. Every word (verb, resource, dimensionality) carries information, and there is nothing to trim.

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?

No output schema and no annotations, so the description should explain what is returned for both the synchronous and asynchronous paths. It leaves the sync=false contract (job handle? immediate return?) and the overwrite semantics of re-embedding completely unexplained, which is insufficient for a tool with an async mode.

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 coverage is 100%, so both 'id' and 'sync' are already documented in the schema. The description adds only the output dimensionality, not any meaning about the parameters; per the baseline rule for full coverage, a 3 is appropriate.

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 ('Calculate') and resource ('city record') plus the output dimension (1024-dimensional vector embedding), which distinguishes it from generate_country_embedding by resource. It stops short of explicitly naming the sibling it is not, but the resource specificity makes the purpose unambiguous.

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?

No indication of when this should be called versus alternatives such as generate_country_embedding or generate_deep_synthesis, and no prerequisites (e.g., must the city exist first, is re-embedding allowed). The agent must infer all usage conditions.

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

Deploy Server