Skip to main content
Glama

Get Player Inventory

horizon_get_items
Read-onlyIdempotent

Reads a player's bounded unique item inventory to open inventory views or reconcile uncertain edits, returning the complete revisioned inventory as a read-only result.

Instructions

Reads the player's bounded unique item inventory. Use when: opening inventory or reconciling an uncertain edit. Not for: polling or minting items; use horizon_get_item_catalog for templates. 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); an absent inventory is returned empty without writing. Returns: Complete {userId,revision,instances,limits,serverTime} inventory. Replace only the matching host/project/player cache. Instances carry server-generated UUIDs, properties, equipped and createdAt. Errors: 409 REVISION_CONFLICT or an uncertain response: use horizon_get_items and reconcile intent, never silently substitute a new revision and repeat. 404 ITEM_NOT_FOUND means this instance no longer exists. 422 ITEM_PROPERTY_NOT_ALLOWED/ITEM_PROPERTY_LIMIT_REACHED rejects the entire adjustment. 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
userIdYesSigned-in player UUID matching the session
sessionTokenYesPlayer accessToken sent only as Authorization Bearer

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?

Goes well beyond the readOnly/idempotent annotations: states side effects (absent inventory returned empty without writing), the full auth flow via horizon_signin_email/anonymous and accessToken-as-sessionToken, the HORIZON_API_KEY requirement, rate-limit behavior (429), and per-status error semantics (401/403/404/409/422).

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 purpose/usage/auth/returns/errors in labeled chunks, but the error paragraph is dense and restates the 401 sign-in retry rule twice. It earns most of its length but could be trimmed without losing meaning.

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 fully documents the return shape ({userId,revision,instances,limits,serverTime}), what instances contain, and cache-replacement guidance. An agent has everything needed to call and interpret the result.

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 baseline is 3, but the description adds real value by explaining how sessionToken is obtained (sign in and pass its accessToken) and reinforcing that userId must be the signed-in player's UUID matching the session.

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?

Opens with a specific verb+resource: 'Reads the player's bounded unique item inventory.' The 'bounded unique item inventory' phrasing distinguishes it from catalog/template reads and from mutation tools like horizon_adjust_item.

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' (opening inventory, reconciling an uncertain edit) and 'Not for' (polling, minting) sections, plus a named alternative (horizon_get_item_catalog for templates) and a retry rule on conflict. Nothing 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