Skip to main content
Glama
ProjectMakersDE

horizOn MCP Server

Official
by ProjectMakersDE
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Get Player Value Offers

horizon_get_player_value_offers
Read-onlyIdempotent

Retrieves configured purchase offers and player value definitions for the current project, preparing a value-offer purchase. Call before buying; it does not change existing balances.

Instructions

Returns configured purchase offers and the player's value definitions for the current project. Use when: preparing a purchase with horizon_purchase_player_value_offer. Not for: buying an offer (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. Side effects: May lazily initialize missing configured values once; does not change existing balances. Returns: {definitionVersion, serverTime, definitions, offers: [{key, name, active, costs, rewards, purchasesPerDay}]} Errors: 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
userIdYesPlayer UUID belonging to the selected project and player session
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.4/5.0
Behavior5/5

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

Goes well beyond the annotations: states the lazy initialization side effect and clarifies it does not alter existing balances, spells out the auth prerequisite (sign-in tool, accessToken as sessionToken, HORIZON_API_KEY), documents the return shape, and enumerates error codes with recovery actions including 401/403/409/429 semantics. The 'may lazily initialize' note is reconciled with readOnlyHint=true rather than contradicting it.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded and well-labeled (Use when / Not for / Requires / Side effects / Returns / Errors), but the error block is inflated with 409 STATE_CONFLICT, OPERATION_CONFLICT and OPERATION_EXPIRED guidance about operation IDs that do not apply to this read-only, operation-ID-free tool. That is template carry-over that dilutes the signal.

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?

No output schema exists, yet the description supplies the exact response shape (definitionVersion, serverTime, definitions, offers with costs/rewards/purchasesPerDay), along with auth flow, side effects and error taxonomy. An agent has everything needed to call it and interpret failures.

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 value by explaining where sessionToken comes from (horizon_signin_email / horizon_signin_anonymous) and what a 403 implies about userId/session pairing. It stops short of describing parameter format constraints, which the schema already handles.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: returns configured purchase offers plus the player's value definitions for the current project, and explicitly says it is not the buying tool. It is clear against horizon_purchase_player_value_offer, but it never reconciles itself with the closely named sibling horizon_get_player_values, which also surfaces value definitions.

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?

Explicit 'Use when: preparing a purchase with horizon_purchase_player_value_offer' plus 'Not for: buying an offer' gives both the positive trigger and the exclusion, naming the alternative tool. Nothing about selection is left to inference.

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