Skip to main content
Glama

Get Friends

horizon_get_friends
Read-onlyIdempotent

Reads a player's friends, incoming/outgoing requests, blocks, and limits as a complete snapshot for social screens or reconciling uncertain mutations.

Instructions

Reads friends, incoming/outgoing requests, blocks and current limits. Use when: opening a social screen or reconciling an uncertain mutation. Not for: polling for online presence or applying old snapshots to a new session. 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: Complete {userId,revision,friendCode,friends,incoming,outgoing,blocked,limits,serverTime} snapshot. Replace the matching host/project/player cache. lastActiveAt is the latest retained login, null when unknown; it is not online presence. Errors: 409 REVISION_CONFLICT or an uncertain response: get a new snapshot and reconcile intent, never silently replace expectedRevision and repeat. 404 FRIEND_REQUEST_NOT_FOUND means this request was removed or replaced; do not act on a newer ID. INBOX_FULL rejects the entire send/accept. Friend/request/block capacity limits reject additions while existing data remains removable. 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.9/5.0
Behavior5/5

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

Beyond the read-only/idempotent annotations, the description explains snapshot replacement semantics, the meaning of lastActiveAt, revision-conflict recovery, request-not-found behavior, inbox/capacity limits, auth failures, API-key failures, and rate-limit behavior. This is unusually rich behavior detail for an agent invoking the tool.

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?

The description is front-loaded and sectioned into use cases, exclusions, requirements, side effects, return shape, and errors. Despite its length, the structure makes every part easy to scan and the detail is justified by the missing output schema and numerous failure modes.

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 compensates by describing the complete returned snapshot fields. It also covers auth acquisition, cache replacement, online-presence semantics, and key error recovery paths, leaving little an agent needs to infer before calling it.

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 already 100%, so the schema documents userId and sessionToken format. The description still adds meaningful operational semantics: userId must match the signed-in player, and sessionToken must come from one of the horizon_signin_* tools as the accessToken.

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?

The description states a specific read operation and enumerates exactly what is read: friends, incoming/outgoing requests, blocks, and limits. It also distinguishes itself from nearby social mutations and explicitly rules out online-presence polling, so an agent can identify its role among 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?

It gives explicit positive triggers (opening a social screen, reconciling an uncertain mutation) and explicit exclusions (polling for online presence, applying old snapshots to a new session). The auth prerequisite also points to the exact sign-in tools whose token should be used.

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