horizOn MCP Server

Official

by ProjectMakersDE

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

Update Player Statistics Batch

horizon_update_statistics

DestructiveIdempotent

Atomically updates a player session's statistic counters in one batch using a persisted operation ID, enabling safe retries after uncertain timeouts without duplicate writes.

Instructions

Applies one explicit atomic session batch with a caller-persisted operation ID. Use when: reporting completed session counters, or retrying exactly the same durable ID and payload after an uncertain timeout. Not for: automatically generating another ID for a failed/unknown outcome, or one HTTP call per counter. Requires: userId and the player's session: sign in with horizon_signin_email or horizon_signin_anonymous and pass its accessToken as sessionToken. Persist the original operationId and unchanged updates before sending. ID is <13-digit Unix milliseconds>:; use the snapshot server operation time for clock alignment. Side effects: Updates all counters atomically. A retained same-ID same-payload receipt replays; changed payload conflicts. Eight receipts and a persistent eviction floor can reject delayed out-of-order unknown IDs even within 24 hours; nothing is rebooked. Returns: The current statistics snapshot with operationId and replayed. Errors: 401 SESSION_REQUIRED: sign in again; 403 SESSION_FORBIDDEN: use the matching player. 409 OPERATION_CONFLICT means the ID was already used for a different payload. 410 OPERATION_EXPIRED rejects an expired/evicted unknown ID. Never replace an uncertain ID automatically. 422 UNKNOWN_STATISTIC/UPDATE_ABOVE_LIMIT/VALUE_OVERFLOW rejects the whole batch. Needs HORIZON_API_KEY. Every failure returns an error result (isError) with the HTTP status and body: a 401 that horizon_test_connection also returns means HORIZON_API_KEY is wrong, 429 means the account's per-minute rate limit was reached (wait a minute, then retry).

Input Schema

Name	Required	Description
`userId`	Yes	Signed-in player UUID matching the supplied session token
`updates`	Yes	Original immutable batch of distinct statistic keys with safe integer values; server enforces the current System Config definition limit, which can exceed tier defaults
`operationId`	Yes	Original durable <13-digit Unix milliseconds>:<UUID> operation ID; reuse unchanged on retry
`sessionToken`	Yes	Player accessToken from horizon_signin_anonymous or horizon_signin_email; sent as Bearer

Output Schema

Name	Required	Description	Default
`userId`	Yes
`values`	Yes
`replayed`	No
`revision`	Yes
`definitions`	Yes
`operationId`	No
`newlyUnlocked`	Yes
`operationWindow`	Yes
`definitionVersion`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.9.1Oct 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 (destructive/idempotent/openWorld) by explaining the exact replay-vs-conflict semantics, the eight-receipt retention and eviction floor that can reject in-window unknown IDs, and that nothing is rebooked. It also documents auth sourcing (accessToken from signin tools), the HORIZON_API_KEY requirement, 401/403/409/410/422 error meanings, and 429 rate-limit handling.

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-loads the core action, then uses labelled sections (Use when / Not for / Requires / Side effects / Returns / Errors) that an agent can scan quickly. It is long and has minor redundancy, e.g. 'Never replace an uncertain ID automatically' repeats the earlier retry rule, but nearly every sentence carries operational weight.

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 a destructive, idempotent mutation with an output schema, the description covers prerequisites, idempotency contract, retention edge cases, return shape (snapshot plus operationId and replayed), and the full failure taxonomy. Nothing an agent needs to call this safely and correctly is missing.

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; the description adds real meaning on top by explaining that the operationId must be persisted and reused verbatim on retry, that updates must stay unchanged, that the userId must match the session's player, and where sessionToken comes from. It does not restate the batch-size or value-range constraints beyond what the schema already enforces.

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: applying one explicit atomic session batch of statistic counter updates with a caller-persisted operation ID. This clearly separates it from horizon_get_statistics (read) and horizon_adjust_player_value (player-values resource), with the atomic-batch scope making the distinction explicit.

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?

Uses explicit 'Use when' and 'Not for' clauses: use for reporting completed session counters or retrying the same durable ID after an uncertain timeout; not for minting new IDs on unknown outcomes or one HTTP call per counter. The alternatives and exclusions are named rather than implied.

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

Deploy Server