Skip to main content
Glama

Sign In with Email

horizon_signin_email

Signs in a registered, verified player using email and password, then returns a session token for authenticated actions like score submission and cloud saves.

Instructions

Signs in an existing email account with email and password and starts a player session (accessToken). Use when: a registered, verified player logs in, before any tool that needs sessionToken (submit score, cloud save, gift code redeem, profile, validated runs). Not for: guest accounts (use horizon_signin_anonymous), new players (use horizon_signup_email) or checking an existing token (use horizon_check_auth). Side effects: creates a new session on every call; older sessions stay valid. Returns: {userId, username, email, accessToken, authStatus, message}. Pass userId and accessToken (as sessionToken) to the session tools; the token stays valid for one hour after its last use. Errors: 401 for a wrong password or unknown email: ask the player to check the credentials. 403 (NOT_VERIFIED) for an unverified email: the player must confirm the verification email first. 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
emailYesEmail address the account was registered with (max 40 characters)
passwordYesAccount password (max 128 characters); sent to the API only, never returned

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv1.6.0
    • changedInput schema / properties / email / description
      Previous value: -"Email address"New value: +"Email address the account was registered with (max 40 characters)"
    • addedInput schema / properties / email / maxLength
      Added value: +40
    • changedInput schema / properties / password / description
      Previous value: -"Password"New value: +"Account password (max 128 characters); sent to the API only, never returned"
    • addedInput schema / properties / password / maxLength
      Added value: +128
    • addedInput schema / properties / password / minLength
      Added value: +1
  2. First observedv1.5.4

TDQS

A4.6/5.0
Behavior5/5

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

Discloses behavior far beyond the annotations: a new session is created on every call while older sessions stay valid, token lifetime of one hour after last use, HORIZON_API_KEY requirement, 401/403 discrimination, isError semantics on every failure, and the 429 per-minute rate limit. This is a model example of documenting side effects and auth needs.

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 the core action, then organized into labeled Use when/Not for/Side effects/Returns/Errors blocks. It is long but dense and well-structured; a few clauses (e.g. the dual-401 explanation) could be tightened, keeping it just short of perfect.

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 non-idempotent, open-world auth tool with no output schema, the description covers purpose, gating, side effects, returned fields, token lifecycle, error codes, and rate limiting. An agent has everything needed to call it and handle outcomes.

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 email and password constraints are already fully documented in the schema. The description only restates that email and password are used and adds post-call guidance (pass userId/accessToken as sessionToken), which is about return usage rather than parameter meaning. Baseline 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+resource ('Signs in an existing email account with email and password and starts a player session'), and goes further by naming the return token. It clearly delineates itself from the signup/anonymous/check siblings.

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' clause (registered, verified player logs in before any sessionToken-dependent tool) plus a 'Not for' clause that names the exact alternative for each rejected case (horizon_signin_anonymous, horizon_signup_email, horizon_check_auth). 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