Skip to main content
Glama

Adjust Player Value

horizon_adjust_player_value
DestructiveIdempotent

Adjusts one player's value by a signed amount within enabled project rules and per-call/daily limits, using a stable operation ID and session token.

Instructions

Adjusts one player value within explicitly enabled project rules and per-call and daily limits. Use when: the configured game permits a direct value adjustment; use horizon_get_player_values to inspect the result. Not for: trusted rewards or arbitrary grants; client adjustment is disabled by default. Purchases use horizon_purchase_player_value_offer. Requires: userId and the player's session: sign in with horizon_signin_email or horizon_signin_anonymous and pass its accessToken as sessionToken. This definition must enable adjustment. Side effects: Applies the signed amount once per operationId. The minimal guard binds the original reason/payload hash without copying the reason. Never creates an ID or retries automatically. Returns: Current state with replayed/alreadyApplied. Fresh success includes its delta; replay has empty applied/items. Errors: ADJUST_NOT_ALLOWED or ADJUST_ABOVE_LIMIT: change the game flow or project rules. 409 STATE_CONFLICT: refresh state and retry the SAME operation ID and payload. OPERATION_CONFLICT: do not reuse an ID for a different action. OPERATION_EXPIRED: reconcile state/history; never silently generate another ID. INSUFFICIENT_BALANCE, MAX_BALANCE_REACHED or DAILY_LIMIT_REACHED leaves the whole operation unapplied. 401 means the session is missing or expired: sign in again and retry with the new accessToken. 403 for a session means the token belongs to another user: pass the userId that signed in. 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

NameRequiredDescriptionDefault
keyYesConfigured value or offer key, 1 to 24 lowercase letters, digits, '.', '_' or '-'
amountYesNonzero signed safe integer delta; limited by the project rules
reasonYesNonblank audit reason, at most 200 UTF-8 bytes
userIdYesPlayer UUID belonging to the selected project and player session
operationIdYesStable operation ID: server-aligned Unix milliseconds + ':' + UUID. Persist before sending; reuse unchanged on timeout or retry
sessionTokenYesPlayer accessToken from sign-in, sent only in the Authorization Bearer header

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.9.1

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare mutation, open-world, idempotent, and destructive behavior, and the description goes well beyond them by explaining operationId replay semantics, no automatic ID creation or retries, full side effects, auth requirements, return states, and specific error meanings. Nothing contradicts the annotations.

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?

The description is long but well front-loaded and explicitly structured with Use when / Not for / Requires / Side effects / Returns / Errors. The density is justified by the mutation, auth, idempotency, and error-handling complexity, though it is close to overloaded.

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?

Given the lack of an output schema and the tool's destructive/idempotent nature, the description supplies the missing operational context: return shape, replay states, error recovery instructions, auth prerequisites, and rate-limit behavior. An agent has enough information to invoke and recover correctly.

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 per-field descriptions already carry most parameter semantics. The tool description adds useful operational meaning beyond the schema, particularly around operationId idempotent replay, signed amount application, and reason/payload guard behavior.

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 ('Adjusts one player value') plus scope constraints (enabled project rules, per-call and daily limits). It explicitly distinguishes itself from horizon_get_player_values and horizon_purchase_player_value_offer, so an agent can route without inferring from sibling names.

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 explicit 'Use when', 'Not for', and alternative-tool guidance, including the purchase alternative and inspection sibling. It also states the prerequisite that adjustment must be enabled and the authentication flow needed before calling.

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

Deploy Server

Other Tools