Skip to main content
Glama

Create Log

horizon_create_log

Write a server-side INFO, WARN, or ERROR log entry for a player to record technical events or handled errors for later debugging in the horizOn dashboard.

Instructions

Writes one server-side log entry (INFO, WARN or ERROR) for a player, visible in the horizOn dashboard's user logs. Use when: the game records a technical event or a handled error for later debugging, for example a failed purchase or a slow load. Not for: crashes and exceptions with a stack trace (use horizon_create_crash_report) or messages written by players (use horizon_submit_feedback). Requires: a userId from horizon_signup_* or horizon_signin_* and the BASIC tier or higher; no session token. Side effects: creates one log entry per call; a repeat creates a duplicate. Returns: {id, createdAt} of the new entry. Errors: 403 on the FREE tier: logs need BASIC or higher, so upgrade or skip logging. 400 for an invalid userId: pass the ID from the sign-in result. 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
typeYesLog level: INFO, WARN or ERROR
userIdYesPlayer user ID (UUID) from horizon_signup_* or horizon_signin_*
messageYesLog message (max 1000 characters)
errorCodeNoOptional code to group entries in the dashboard, useful with ERROR, for example 'IAP_TIMEOUT' (max 50 characters)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv1.6.0
    • changedInput schema / properties / errorCode / description
      Previous value: -"Error code (max 50 characters)"New value: +"Optional code to group entries in the dashboard, useful with ERROR, for example 'IAP_TIMEOUT' (max 50 characters)"
    • changedInput schema / properties / type / description
      Previous value: -"Log level: INFO, WARN, or ERROR"New value: +"Log level: INFO, WARN or ERROR"
    • changedInput schema / properties / userId / description
      Previous value: -"User ID (UUID) returned by a horizon_signup_* or horizon_signin_* tool"New value: +"Player user ID (UUID) from horizon_signup_* or horizon_signin_*"
  2. Changed1 schema field changedv1.5.5
    • changedInput schema / properties / userId / description
      Previous value: -"User ID (UUID)"New value: +"User ID (UUID) returned by a horizon_signup_* or horizon_signin_* tool"
  3. First observedv1.5.4

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare this as a non-idempotent, non-destructive write, and the description adds substantial context beyond that: one entry created per call with duplicates on repeat, the exact return shape ({id, createdAt}), tier-gated 403 behavior, 400 for bad userId, 401 API-key mismatch, and 429 per-minute rate limiting with a retry recommendation. It is fully consistent with the annotations.

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-loads the core action and uses clear labeled sections (Use when, Not for, Requires, Side effects, Returns, Errors) that make scanning easy. Some content is redundant, such as restating the BASIC-tier requirement in the 403 error note, which slightly dilutes an otherwise tight structure.

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?

For a four-parameter write tool with no output schema, the description covers purpose, routing to siblings, auth requirements, side effects, return shape, and the expected error modes. An agent has everything needed to invoke it correctly and interpret failures without opening other resources.

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 description coverage is 100%, so all four parameters already have in-schema documentation (type enum, userId UUID source, message max length, errorCode grouping). The description restates the userId source and INFO/WARN/ERROR levels but adds no syntax or format detail beyond the schema, so the baseline of 3 applies.

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 ('Writes one server-side log entry ... for a player') and pins the scope to the horizOn dashboard. It explicitly distinguishes itself from the two nearest siblings by naming horizon_create_crash_report and horizon_submit_feedback as different use cases.

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 explicit 'Use when' and 'Not for' clauses, and the exclusion names the correct alternative tool for each case (crash report with stack trace, player-written feedback). Prerequisites (userId source, BASIC tier, no session token) are also stated, leaving nothing to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.