Skip to main content
Glama
ProjectMakersDE

horizOn MCP Server

Official
by ProjectMakersDE
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Create Crash Session

horizon_create_crash_session

Registers a new app run session so horizOn can calculate crash-free session rates. Call at every app start with a unique sessionId, then use that ID when reporting a crash.

Instructions

Registers one app run (session) so horizOn can calculate the crash-free session rate. Use when: once at every app start, with a new unique sessionId; keep that ID for horizon_create_crash_report. Not for: reporting the crash itself (use horizon_create_crash_report) or player sign-in sessions (those come from horizon_signin_*). Side effects: records one session per call; a later crash report with the same sessionId marks it as crashed. Returns: {status: 'ok'}. Errors: 400 when a field is missing or too long: fix it and resend. 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

TableJSON Schema
NameRequiredDescriptionDefault
userIdNoPlayer user ID (UUID) from horizon_signup_* or horizon_signin_*, if a player is signed in
platformYesPlatform (e.g. 'Android', 'iOS', 'Windows')
sessionIdYesNew unique ID for this app run, for example a UUID generated at start (1 to 100 characters)
appVersionYesApp version (e.g. '1.2.3')

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.6.0
    • changedInput schema / properties / sessionId / description
      Previous value: -"Unique session identifier (1-100 characters)"New value: +"New unique ID for this app run, for example a UUID generated at start (1 to 100 characters)"
    • changedInput schema / properties / userId / description
      Previous value: -"User ID (UUID) starting the session"New value: +"Player user ID (UUID) from horizon_signup_* or horizon_signin_*, if a player is signed in"
  2. First observedv1.5.4

TDQS

A4.9/5.0
Behavior5/5

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

Beyond the annotations, it discloses the side effect (one session recorded per call; a later crash report with the same sessionId marks it crashed), the return value, and a full error taxonomy: 400 validation, HORIZON_API_KEY requirement, 401 vs horizon_test_connection, and 429 per-minute rate limiting with retry guidance.

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

Conciseness5/5

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

Labeled sections (Use when / Not for / Side effects / Returns / Errors) make it skimmable, and the core purpose leads. Every sentence carries operational information; nothing is padding.

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 supplies the return shape, the safety-relevant side effect, cross-tool ID reuse, and the error contract, which is more than enough for a 4-parameter ingest call.

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 description coverage is 100%, so the baseline is 3, but the description adds lifecycle meaning the schema lacks: sessionId must be new and unique per run and must be kept for horizon_create_crash_report. It does not add much about userId, platform, or appVersion 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 ('Registers one app run (session)') plus the downstream purpose ('so horizOn can calculate the crash-free session rate'). It distinguishes itself from horizon_create_crash_report and the horizon_signin_* family without the reader needing to open a schema.

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' (once at every app start, with a new unique sessionId) and 'Not for' clauses that name the correct alternatives (horizon_create_crash_report for the crash itself, horizon_signin_* for player sessions). It even states the caller must retain the sessionId for the later report call.

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