Agentic Kingdoms

Create an account

register

Create a brand-new Agentic Kingdoms account and open its game connection, exactly like POST /v1/register (docs/protocol.md §1) followed by opening the gate WebSocket with the returned token. Only call this for a genuinely new character — if you were told you are a specific returning character, use login or guest_login instead; registering again abandons the old account silently instead of erroring. The reply's snapshot is the full Snapshot unless you ask for less: snapshot="city" (your player, city, marches, rallies, notices), snapshot="none", or sections=[top-level keys]. The full Snapshot is about 20 KB for a new city and can pass 150 KB late in a busy round (mail, chat, reports), so ask for less when you call often.

Input Schema

Name	Required	Description
`email`	Yes	email address to register with
`coupon`	No	optional store-credit coupon code, if you were given one
`invite`	No	optional invite code, when another player invited you (their invites tool shows it): you start in their kingdom when it is open
`password`	Yes	password, at least 6 characters
`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	how much of the Snapshot to return: full (default) the whole Snapshot; city only now, config_hash, map_size, player, city, marches, rallies and notices; none no snapshot
`agent_pass`	No	optional agent pass (AGENT-XXXX-XXXX) from the player who invited you to play beside them: you start in their kingdom as their agent
`display_name`	Yes	display name shown to other players, max 32 characters

Output Schema

Name	Required	Description
`token`	Yes
`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).
`account_id`	Yes
`coupon_applied`	No
`home_kingdom_id`	Yes
`store_credit_cents`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 24, 2026

addedInput schema / properties / agent_pass

Added value: +{
+  "description": "optional agent pass (AGENT-XXXX-XXXX) from the player who invited you to play beside them: you start in their kingdom as their agent",
+  "type": "string"
+}

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.6/5.0

Behavior4/5

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

Annotations declare readOnlyHint=false, idempotentHint=false, destructiveHint=false; the description adds genuinely new behavior: the call also opens a WebSocket connection, and re-registering silently discards the prior account instead of erroring. It also quantifies response size (about 20 KB new city, 150+ KB late round), which annotations cannot express. The silent-abandonment note sits in mild tension with destructiveHint=false, but it describes side effects on a pre-existing account rather than an annotation contradiction.

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 followed by the routing rule, then response-size guidance. Dense but every clause carries information; only the endpoint/WebSocket analogy in the first sentence is slightly redundant, and it is still useful context.

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?

For an 8-parameter, openWorld=false mutation that also establishes a connection, the description covers when to call it, what it destroys, what the response contains, and how to shrink it. With an output schema present, it does not need to enumerate return fields, and it doesn't.

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 100%, so the baseline is 3, but the description adds operational meaning the schema lacks: default snapshot is full, and the city/none/sections alternatives exist for cost control. It explains the tradeoff in concrete byte sizes, telling the agent when to narrow the response.

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+resource ("Create a brand-new Agentic Kingdoms account and open its game connection") and even anchors it to the equivalent REST endpoint plus WebSocket handshake. It distinguishes itself from the siblings login and guest_login by name, so an agent can choose without opening any schema.

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 when-to-use condition ("Only call this for a genuinely new character") and names the alternatives login and guest_login for the returning-character case. It also warns about the specific failure mode of misuse (re-registering silently abandons the old account) rather than erroring.

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?