Skip to main content
Glama
ProjectMakersDE

horizOn MCP Server

Official
by ProjectMakersDE
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Find Player by Friend Code

horizon_find_player
Read-onlyIdempotent

Finds one public player by exact UUID or canonical H- friend code when an ID is intentionally shared; requires a signed-in session token.

Instructions

Finds one public player by exact UUID or canonical H- friend code in this project. Use when: a player intentionally shares their ID or friend code. Not for: email/name search, enumerating players or testing online presence. 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: {userId,friendCode,display:{name,profile}}. Unknown, inactive, deleted, foreign and blocked players share PLAYER_NOT_FOUND. 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
queryYesPublic UUID or H-code; not a credential and never an email/name prefix
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/5.0
Behavior3/5

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

The annotations already declare a read-only, idempotent, non-destructive, open-world operation, and the description usefully adds 'Side effects: None', the return shape, auth prerequisites, and 401/403/429 handling. However, the long error section is contaminated with unrelated mutation/friend-request/inbox/revision-conflict behavior, which is misleading context for a simple player lookup.

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

Conciseness2/5

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

The purpose, usage, auth, side effects, and return shape are front-loaded and clearly labeled, but the description is bloated by a large error block that mostly describes unrelated friend-request, inbox, and revision-conflict flows. Many sentences do not earn their place for this read-only lookup tool.

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?

For a 3-parameter read-only lookup with full schema coverage and rich annotations, the description includes the important missing pieces: auth acquisition, query form, return shape, and relevant 401/403/429 behavior. Its completeness is undermined by irrelevant and potentially confusing error cases such as 409 REVISION_CONFLICT, FRIEND_REQUEST_NOT_FOUND, and INBOX_FULL.

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 100%, so the schema already documents the three parameters well. The description still adds value by clarifying that query is exact UUID or canonical H-code and by explaining that sessionToken is the accessToken from horizon_signin_email or horizon_signin_anonymous, and that userId must match the signed-in player.

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 verb and resource: finds one public player by exact UUID or canonical H- friend code in this project. It also clearly scopes the tool away from email/name search, enumeration, and presence testing, which distinguishes it from nearby player/friend tools.

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 when-to-use guidance (player intentionally shares ID or friend code) and explicit when-not-to-use cases (email/name search, enumerating players, testing online presence). It also names sign-in alternatives for obtaining the required session token.

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