Skip to main content
Glama
ProjectMakersDE

horizOn MCP Server

Official
by ProjectMakersDE
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Open Chat Channel

horizon_open_chat_channel
Idempotent

Opens a direct, group, or project chat channel under current permissions, establishing a deterministic hosted chat session before you sync or send messages.

Instructions

Opens deterministic direct, group or project chat under current permissions. Use when: explicit hosted chat actions after reading horizon://docs/chat. Not for: automatic sends, repeated polling, rich-text rendering or exposing moderation credentials. Use horizon_get_chat_operation to reconcile original sends, then horizon_send_chat_message only for the explicit identical replay. 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: One HTTP attempt. Existing live open is a no-op. A new/expired channel allocates a fresh epoch under quota/rate gates. Subscribe before first sync/send. Returns: {channel,serverTime} Errors: 404 hides private/missing/expired channels or source messages. 409 OPERATION_CONFLICT/OPERATION_EXPIRED or STATE_CONFLICT requires explicit original-intent reconciliation. Never replace an unknown send UUID/time/text. 429 does not schedule a retry. CHAT_MUTED/CHAT_BANNED restrict current chat access. 501 NOT_SUPPORTED means simpleServer has no chat or polling fallback. 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
kindYesChat audience under current friend or group permissions
peerIdNoRequired only for a direct channel with this other player
userIdYesActive player matching the current session and project
groupIdNoRequired only for a channel of this current group
sessionTokenYesPlayer accessToken sent only as Bearer

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.9.1

TDQS

A4.6/5.0
Behavior5/5

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

Annotations declare idempotent, non-destructive, open-world, so the bar is lower, yet the description still adds substantial context: single HTTP attempt, live-open no-op, epoch allocation under quota/rate gates, subscribe-before-sync ordering, and a full error taxonomy including 404/409/429/muted/501 semantics. It also flags the HORIZON_API_KEY dependency and the 401 vs 403 distinction for session tokens.

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 purpose and organized into labeled Use when/Not for/Requires/Side effects/Returns/Errors sections, which makes it easy to scan. The Errors paragraph is long and dense, bordering on kitchen-sink, but every clause carries operationally relevant information.

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 state-changing, open-world chat tool with no output schema, the description covers returns ({channel, serverTime}), side effects, ordering requirements, auth provenance, and error recovery paths. An agent has essentially everything needed to call this correctly and handle failures.

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 the schema already documents kind, peerId, groupId, userId and sessionToken, including the conditional-required semantics. The description only restates that userId and sessionToken are required and where the token comes from; it adds little on peerId/groupId conditional behavior beyond what the schema says, so 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?

The opening sentence gives a specific verb (opens) and resource (deterministic direct, group or project chat) with a scoping condition (under current permissions). It clearly separates this from related siblings, and the subsequent 'use when/not for' framing makes the boundary unambiguous.

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?

Explicitly states when to use (explicit hosted chat actions after reading the docs), when not to use (automatic sends, polling, rendering, credential exposure), and names the exact alternatives: horizon_get_chat_operation for reconciliation and horizon_send_chat_message only for identical replay.

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