Skip to main content
Glama

Get Player Inbox

horizon_get_inbox
Read-onlyIdempotent

Read targeted player messages and eligible project broadcasts with counts and polling intervals to display notifications or refresh cached entries after realtime invalidation.

Instructions

Reads targeted messages and eligible project broadcasts, counters and server polling interval. Use when: displaying notifications or refreshing after realtime invalidation. Not for: choosing rewards or writing messages from the player client. 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: None (read only). Returns: {userId,cursor,revision,broadcastRevision,serverTime,pollAfterSeconds,unchanged,entries,counts,limits}. unchanged=true has empty entries: keep the cached entries. A changed snapshot replaces them completely. Errors: 409 STATE_CONFLICT: retry the same entry ID. UNCLAIMED_REWARD: claim before removal. MAX_BALANCE_REACHED/DAILY_LIMIT_REACHED/INVENTORY_FULL leaves the reward or original item unclaimed. ENTRY_NOT_FOUND after removal/cleanup never grants again. 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
sinceNoOpaque cursor from this same player/project; omit for a full snapshot
userIdYesPlayer UUID belonging to the selected project and player session
sessionTokenYesPlayer accessToken, sent only as Authorization Bearer

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.9.1

TDQS

A4.5/5.0
Behavior5/5

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

Beyond the read-only annotations, the description discloses authentication requirements, absence of side effects, return-shape semantics, cache behavior for unchanged snapshots, and a detailed error taxonomy. This is unusually thorough behavioral context for an agent.

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?

The description is front-loaded with purpose, usage, requirements, and side effects, which is good. However, it is very long and packs in an extensive error taxonomy, making it denser and less concise than necessary even for a complex read tool.

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?

With no output schema, the description compensates by documenting the return fields, unchanged-snapshot behavior, authentication source, and relevant error states. An agent has enough context to call and interpret this tool 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 already 100%, so the schema documents all three parameters. The description still adds meaningful provenance for sessionToken by explaining that it is the accessToken from a sign-in call, though it does not further explain the since cursor beyond the schema.

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?

The description names a specific read operation over targeted messages and project broadcasts, including counters and polling metadata. It also distinguishes the tool from adjacent inbox actions by stating it is not for choosing rewards or writing messages.

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

Usage Guidelines4/5

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

It gives explicit use-when guidance for notifications and realtime invalidation, plus a not-for exclusion. However, it does not explicitly route the agent to the relevant sibling tools for marking, claiming, or removing inbox entries, despite referencing claim/removal behavior in errors.

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