EasyTerritory MCP

Set Map State

set_map_state

Read-onlyIdempotent

Changes the open map's session state: mode, active alignment (active_tal_id), pending job reference, or camera (center [longitude, latitude] and zoom 0-24). Session only: the Territory Solution is not changed (configure_map sets a durable default view). The result's render_ack is read at publish time, so sent_unconfirmed one version behind is normal; render_ack_hint says whether to reread ezt://map-sessions/{map_session_id}/state or resend. camera reports the view in effect and its source (requested, session, map_config, or viewer_current). A set camera stays until changed; switching alignment does not refit.

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": {
      "map_session_id": "<map_session_id>"
    },
    "name": "set_map_state"
  }
}

Input Schema

Name	Required	Description
`mode`	No
`zoom`	No
`center`	No
`active_tal_id`	No	Alignment to make active on the open map (session only).
`map_session_id`	Yes	Open map session (msess_...) from get_map_visualization.
`pending_job_reference`	No	Task reference (task_id from a build submission) the map follows and repaints from when the task completes.

Output Schema

Name	Required	Description
`ok`	Yes
`error`	No	Present when ok is false.
`result`	No	Present when ok is true.
`warnings`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed8 schema fields changedNov 1, 2026

addedInput schema / properties / active_tal_id / description

Added value: +"Alignment to make active on the open map (session only)."

addedInput schema / properties / map_session_id / description

Added value: +"Open map session (msess_...) from get_map_visualization."

changedInput schema / properties / pending_job_reference / anyOf

Previous value: -[
-  {
-    "additionalProperties": true,
-    "type": "object"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "properties": {
+      "job_id": {
+        "description": "Same value as task_id.",
+        "type": "string"
+      },
+      "task_id": {
+        "type": "string"
+      },
+      "tool_name": {
+        "type": "string"
+      }
+    },
+    "type": "object"
+  },
+  {
+    "type": "null"
+  }
+]

addedInput schema / properties / pending_job_reference / description

Added value: +"Task reference (task_id from a build submission) the map follows and repaints from when the task completes."

removedOutput schema / additionalProperties
```
Removed value: -true
```

addedOutput schema / properties

Added value: +{
+  "error": {
+    "description": "Present when ok is false.",
+    "properties": {
+      "ask_user": {
+        "items": {
+          "type": "string"
+        },
+        "type": "array"
+      },
+      "code": {
+        "type": "string"
+      },
+      "details": {
+        "type": "object"
+      },
+      "do_this_next": {
+        "type": "object"
+      },
+      "message": {
+        "type": "string"
+      }
+    },
+    "type": "object"
+  },
+  "ok": {
+    "type": "boolean"
+  },
+  "result": {
+    "description": "Present when ok is true.",
+    "type": "object"
+  },
+  "warnings": {
+    "items": {
+      "properties": {
+        "code": {
+          "type": "string"
+        },
+        "message": {
+          "type": "string"
+        }
+      },
+      "type": "object"
+    },
+    "type": "array"
+  }
+}

addedOutput schema / required
```
Added value: +[
+  "ok"
+]
```

removedOutput schema / title

Removed value: -"set_map_stateDictOutput"

Changed1 schema field changedOct 9, 2026

removedInput schema / properties / guidance_handle

Removed value: -{
-  "anyOf": [
-    {
-      "type": "string"
-    },
-    {
-      "type": "null"
-    }
-  ],
-  "default": null,
-  "title": "Guidance Handle"
-}

First observedSep 29, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Despite readOnlyHint/idempotentHint being declared, the description adds substantial non-redundant behavior: render_ack is sampled at publish time, so a stale 'sent_unconfirmed' one version behind is expected, and render_ack_hint dictates whether to reread the session state resource or resend. It also discloses that a set camera persists until changed and that switching alignment does not refit, which an agent could not infer from annotations. The 'session only, not persisted to the Territory Solution' line also explains why readOnlyHint=true is consistent rather than contradictory.

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 and the four mutable facets, then the session-vs-persistent constraint, then render_ack guidance. Sentences are dense and mostly earn their place, though the render_ack/render_ack_hint clause is packed tightly enough to require a second read.

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 the description still explains render_ack and render_ack_hint behavior usefully. For a 6-parameter session-mutation tool the coverage is strong except for the unexplained 'mode' parameter, whose accepted values remain a blind spot.

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 50% schema coverage, the description compensates well for the undocumented parameters: it specifies center as [longitude, latitude] and zoom as 0-24, and reinforces active_tal_id and pending_job_reference semantics. The notable gap is 'mode', which is neither described in the schema nor given any example values in the description, leaving its domain entirely opaque.

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 (changes) and resource (the open map's session state) and enumerates the four mutable facets: mode, alignment, pending job reference, and camera. It explicitly distinguishes itself from the sibling configure_map by contrasting session state with a durable default view, so an agent can route correctly without reading either schema.

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?

The parenthetical '(configure_map sets a durable default view)' plus 'Session only: the Territory Solution is not changed' gives a clear selection rule between the two tools. It stops short of an explicit 'do not use this to persist a view' exclusion or scenarios, but the context is unambiguous.

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

All EasyTerritory MCP tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?