Skip to main content
Glama

Get Statistics Definitions

horizon_get_statistics_definitions
Read-onlyIdempotent

Retrieves statistics definitions by version so you can show counter labels, modes, reset policies, and report bounds without loading player values.

Instructions

Reads the project's statistics catalog conditionally by version. Use when: showing counter labels, modes, reset policies and optional report bounds. Not for: loading player counter values; use horizon_get_statistics. 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: {definitionVersion, definitions}; definitions null means unchanged, an empty array means an empty catalog. 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

NameRequiredDescriptionDefault
sessionTokenYesPlayer accessToken from horizon_signin_anonymous or horizon_signin_email; sent as Bearer
definitionVersionNoLast cached definitionVersion; omit to load the full catalog

Output Schema

NameRequiredDescriptionDefault
definitionsYes
definitionVersionYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.9.1

TDQS

A3.9/5.0
Behavior3/5

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

Adds real value beyond the annotations: the sign-in prerequisite and accessToken-as-sessionToken flow, the read-only side effect, and the meaningful return semantics (null definitions = unchanged, empty array = empty catalog). However, the long error block includes codes that do not apply to a read operation — 409 OPERATION_CONFLICT about an ID reused for a different payload, 410 OPERATION_EXPIRED about an evicted ID, and 422 UNKNOWN_STATISTIC/UPDATE_ABOVE_LIMIT 'rejects the whole batch' — which read like boilerplate from the statistics-update tool and could mislead an agent debugging a failed read.

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 front half is well structured with labeled Use when / Not for / Requires / Returns / Errors sections and the key routing fact is front-loaded. The errors paragraph is disproportionately long and contains several irrelevant codes, undermining the conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Auth flow, read-only nature, and return semantics are all covered, and an output schema exists so return values needn't be spelled out in detail. The gap is the irrelevant update-oriented error codes, which make the error guidance untrustworthy for this specific read tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so both parameters are already documented, including 'omit to load the full catalog'. The phrase 'conditionally by version' and the null-means-unchanged return note add modest context but no new syntax, format, or constraint 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?

States a specific verb and resource ('Reads the project's statistics catalog') plus the version-conditional scope. It is clearly distinguishable from horizon_get_statistics, which the description explicitly names as the counter-values tool.

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?

Has an explicit 'Use when' clause (counter labels, modes, reset policies, report bounds) and an explicit 'Not for' clause that routes the agent to horizon_get_statistics for player values. 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