Skip to main content
Glama

Realign Parts

realign
Destructive

Moves ZIPs or other parts (typed ids or ones selected on the map) from one territory into another within one alignment (tal_id): a ZIP move. moves=[{part_id, to_territory_id}], or realign_operation with part_ids. The Territory Solution comes from map_session_id (the open map), ts_handle, or ts; expected_revision adds optimistic concurrency (STALE_TS_REVISION when the map changed). to_territory_id is a leaf territory_id or that leaf's exact, unique display name; an unknown or ambiguous value returns UNKNOWN_TERRITORY_ID or AMBIGUOUS_TERRITORY with available_leaf_territories. A committed map selection is read with get_map_selection; request_part_selection lets the person pick parts on the map. remove_empty_territories drops leaves left with no parts. Returns a task; the open map repaints. analyze refreshes statistics when the map has account points.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tsNo
movesNo
tal_idYes
part_idsNo
ts_handleNo
part_layerNo
repair_policyNoTopology repair for dissolved territories. default fills interior holes in the dissolved geometry (no part is added or reassigned; repair_summary.changed_part_ids lists the territories' own parts). report_only detects holes and changes nothing (warning REPAIR_AVAILABLE). strict fails with REPAIR_REQUIRED when a hole is found.default
map_session_idNo
expected_revisionNo
realign_operationNo
remove_empty_territoriesNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • removedInput schema / properties / guidance_handle
      Removed value: -{
      -  "anyOf": [
      -    {
      -      "type": "string"
      -    },
      -    {
      -      "type": "null"
      -    }
      -  ],
      -  "default": null,
      -  "title": "Guidance Handle"
      -}
  2. Changed2 schema fields changed
    • addedInput schema / properties / repair_policy / description
      Added value: +"Topology repair for dissolved territories. default fills interior holes in the dissolved geometry (no part is added or reassigned; repair_summary.changed_part_ids lists the territories' own parts). report_only detects holes and changes nothing (warning REPAIR_AVAILABLE). strict fails with REPAIR_REQUIRED when a hole is found."
    • addedInput schema / properties / repair_policy / enum
      Added value: +[
      +  "default",
      +  "strict",
      +  "report_only"
      +]
  3. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Well beyond the annotations (destructive/not idempotent), it discloses the mutation model, optimistic concurrency via expected_revision with STALE_TS_REVISION, specific failure codes (UNKNOWN_TERRITORY_ID, AMBIGUOUS_TERRITORY with available_leaf_territories), the effect of remove_empty_territories, the returned task and map repaint, and the analyze refresh behavior.

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?

Front-loaded with the core action, then the input shapes, error semantics and side effects. Dense but every clause earns its place; slightly long single-paragraph form costs it the top mark.

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

Completeness4/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 needn't be spelled out, yet it usefully notes a task is returned and the map repaints. Error, concurrency and alternative-tool behaviour are all covered; only the unmentioned part_layer keeps it from being fully complete for an 11-parameter tool.

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?

With only 9% schema coverage the description has to carry the load, and it does for moves, part_ids, realign_operation, ts/ts_handle/map_session_id, expected_revision, to_territory_id (leaf id or exact unique display name) and remove_empty_territories. It is not exhaustive: part_layer is never mentioned and the repair_policy nuance is left to 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 (moves) plus resource (ZIPs/parts between territories within one alignment, tal_id) and explicitly scopes it as 'a ZIP move'. This is clearly distinguishable from siblings like territory_merge, territory_split and territory_rebalance, which are bulk topology operations.

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?

It routes the agent through the selection workflow (get_map_selection for a committed selection, request_part_selection to have a person pick parts) and names the alternative input shape (realign_operation with part_ids). It does not, however, state when to prefer realign over sibling operations like territory_rebalance or territory_merge.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources