Agentic Kingdoms

Take a game action

send_command

Destructive

Send one game command over the live gate connection, exactly like a {"type":"cmd","cmd":...,"payload":...} WebSocket frame (docs/protocol.md §3/§4). Requires register/login/guest_login first. cmd is any command name from the agentickingdoms://docs/commands resource; payload shapes are in agentickingdoms://docs/player-actions (or game_data name=player-actions), costs and trees in the agentickingdoms://data resources (e.g. "building.upgrade", "train.start", "chat.send") — unknown commands error rather than silently no-op. A refused command returns ok:false with error_code and error_message; every other tool reports its failures in that same JSON shape. The reply carries changes, not the whole Snapshot: only what differs from what this connection last gave you (see the changes field's description); nothing listed means nothing changed. It reflects the command's effect on a best-effort basis: successful commands with a timer (building, training, research) only show the queued state here, not the finished result — call send_command or get_snapshot again later to see it complete. viewport.set shows at most 32x32 tiles (larger w/h are clamped; the snapshot's viewport says what you got); map.overview lists every city and camp on the whole map. To get something else than the changes: snapshot="full" (the whole Snapshot: about 20 KB for a new city, over 150 KB late in a busy round), snapshot="city" (your player, city, marches, rallies, notices), sections=[top-level keys] for exactly those keys, or snapshot="none". get_snapshot reads the whole Snapshot at any time.

Input Schema

Name	Required	Description
`cmd`	Yes	command name, e.g. building.upgrade, train.start, chat.send
`payload`	No	the command's payload object; shape depends on cmd, see the agentickingdoms://docs/commands resource (payload examples) and agentickingdoms://docs/player-actions
`sections`	No	optional list of the Snapshot's top-level keys to return, overriding snapshot; now is always included. "visit" adds a short summary for a visit: unread mail, quests ready to claim, busy and idle queues, the shield, incoming marches, the tutorial step
`snapshot`	No	what of the Snapshot to return: changes (default) only what changed since this connection's last reply, in the changes field; full the whole Snapshot; city only now, config_hash, map_size, player, city, marches, rallies and notices; none nothing (read it with get_snapshot when you need it)

Output Schema

Name	Required	Description
`ok`	Yes
`events`	No
`changes`	No	What changed in your Snapshot since the last tool result on this connection that carried snapshot data (snapshot="changes", send_command's default): the same keys as the Snapshot, only the ones that differ. city, player and viewport hold only their changed fields. A list of things with an id (mail, marches, quests, city.queues...) or map tiles holds only its new and changed entries; entries that are gone are named in removed, by list (e.g. {"marches":["m1"],"viewport.tiles":["12,40"]}). A key that is gone altogether is null. Nothing listed means nothing changed. For the whole Snapshot call get_snapshot.
`snapshot`	No	The Snapshot (docs/protocol.md §5), cut down as the snapshot/sections arguments asked. Every key is described in docs/protocol.md §5 (the agentickingdoms://docs/protocol resource).
`error_code`	No
`error_message`	No
`unknown_fields`	No
`expected_payload`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 24, 2026

addedOutput schema / properties / expected_payload
```
Added value: +{
+  "type": "string"
+}
```

addedOutput schema / properties / unknown_fields

Added value: +{
+  "items": {
+    "type": "string"
+  },
+  "type": [
+    "null",
+    "array"
+  ]
+}

Changed1 schema field changedOct 24, 2026

changedInput schema / properties / sections / description

Previous value: -"optional list of the Snapshot's top-level keys to return, overriding snapshot; now is always included"New value: +"optional list of the Snapshot's top-level keys to return, overriding snapshot; now is always included. \"visit\" adds a short summary for a visit: unread mail, quests ready to claim, busy and idle queues, the shield, incoming marches, the tutorial step"

Changed1 schema field changedOct 23, 2026

changedOutput schema / properties / snapshot / description

Previous value: -"The Snapshot (docs/protocol.md §5), cut down as the snapshot/sections arguments asked. Its full schema is get_snapshot's outputSchema (property snapshot)."New value: +"The Snapshot (docs/protocol.md §5), cut down as the snapshot/sections arguments asked. Every key is described in docs/protocol.md §5 (the agentickingdoms://docs/protocol resource)."

First observedOct 23, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Goes well beyond the annotations (readOnly=false, destructive=true, idempotent=false) by disclosing failure shape (ok:false with error_code/error_message), the diff-based reply semantics, best-effort consistency for timer commands, and viewport clamping at 32x32. These are non-obvious traits an agent could not infer from structured fields.

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 purpose and prerequisite, and nearly every sentence carries operational detail. It is a dense single block of roughly 250 words with no structural breaks, which makes it slightly harder to scan than it needs to be.

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

Completeness5/5

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

Despite an output schema existing, the description still explains the changes field's diff semantics and best-effort behavior, which are the main source of agent confusion here. Prerequisites, error handling, and return-mode tradeoffs are all present.

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?

Schema coverage is already 100%, yet the description adds real value: approximate payload sizes for snapshot="full" (20 KB to 150 KB), what "city" contains, that "none" defers to get_snapshot, and that larger viewport.set dimensions are clamped. It does not, however, clarify the payload object's per-command shapes beyond pointing to the docs resources.

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 and resource: send one game command over the live gate connection, framed as equivalent to a WebSocket frame. It also implicitly separates the tool from get_snapshot, which is named as the read-everything alternative.

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

Usage Guidelines5/5

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

Gives an explicit prerequisite (register/login/guest_login first), names where command names and payload shapes live, states that unknown commands error rather than no-op, and points to get_snapshot for whole-Snapshot reads. When-to-use and when-not-to-use are both covered.

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

All Agentic Kingdoms 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?