Skip to main content
Glama
ProjectMakersDE

horizOn MCP Server

Official
by ProjectMakersDE
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Submit Feedback

horizon_submit_feedback

Sends player feedback, bug reports, or feature requests to the developer's feedback inbox in the horizOn dashboard. Use when a player submits a form in your game.

Instructions

Sends a message written by a player (bug report, feature request or comment) to the developer's feedback inbox in the horizOn dashboard. Use when: the player fills in a feedback or bug report form in the game. Not for: crashes and caught exceptions (use horizon_create_crash_report) or technical events the game logs by itself (use horizon_create_log). Requires: a userId from horizon_signup_* or horizon_signin_*; no session token. Side effects: creates one feedback entry per call; a repeat creates a duplicate. Returns: the text "ok" when the entry was stored. Errors: An unknown userId, or one of another API key, is rejected: pass the ID from the sign-in result. 403 when the account's feedback limit is reached: delete old feedback in the dashboard. 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
emailNoContact email address for a reply, if the player wants one
titleYesShort summary shown in the dashboard list (1 to 100 characters)
userIdYesPlayer user ID (UUID) from horizon_signup_* or horizon_signin_*
messageYesFull feedback text (1 to 2048 characters)
categoryNoFree text category (max 50 characters); the horizOn SDKs use BUG, FEATURE and GENERAL. Omit for none
deviceInfoNoDevice and OS details for bug reports, for example 'Pixel 8, Android 14' (max 500 characters)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv1.6.0
    • changedInput schema / properties / category / description
      Previous value: -"Feedback category, free text such as BUG, FEATURE or GENERAL (max 50 characters)"New value: +"Free text category (max 50 characters); the horizOn SDKs use BUG, FEATURE and GENERAL. Omit for none"
    • changedInput schema / properties / deviceInfo / description
      Previous value: -"Device information (max 500 characters)"New value: +"Device and OS details for bug reports, for example 'Pixel 8, Android 14' (max 500 characters)"
    • changedInput schema / properties / email / description
      Previous value: -"Contact email address"New value: +"Contact email address for a reply, if the player wants one"
    • changedInput schema / properties / message / description
      Previous value: -"Feedback message (1-2048 characters)"New value: +"Full feedback text (1 to 2048 characters)"
    • changedInput schema / properties / title / description
      Previous value: -"Feedback title (1-100 characters)"New value: +"Short summary shown in the dashboard list (1 to 100 characters)"
    • 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. Changed2 schema fields changedv1.5.5
    • changedInput schema / properties / category / description
      Previous value: -"Feedback category (max 50 characters)"New value: +"Feedback category, free text such as BUG, FEATURE or GENERAL (max 50 characters)"
    • 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.7/5.0
Behavior5/5

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

Although annotations already cover the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false), the description adds substantial context beyond them: one entry per call with duplicates on repeat, the literal 'ok' return, required HORIZON_API_KEY, 403 feedback-limit behavior, and a full error taxonomy including 401 vs 429 diagnosis. This is rich, actionable behavioral disclosure 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.

Conciseness5/5

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

Labeled sections (Use when / Not for / Requires / Side effects / Returns / Errors) make it highly scannable, and the core purpose is front-loaded. Despite its length, each block carries distinct operational information an agent needs.

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 mutation tool with no output schema, the description covers auth requirements, side effects, the return value, and the full failure surface including status-code interpretation. Nothing an agent needs to call it correctly is missing.

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 all six parameters with formats and length limits. The description reinforces userId provenance (from horizon_signup_*/horizon_signin_*) and the session-token-free requirement, but adds little semantic detail the schema lacks. Baseline 3 is appropriate.

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 ('Sends a message written by a player ... to the developer's feedback inbox') and enumerates the content types (bug report, feature request, comment). It explicitly names the siblings it is not, so an agent can distinguish it from horizon_create_crash_report and horizon_create_log without opening any schema.

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?

Provides an explicit 'Use when' (player fills in a feedback/bug report form) and an explicit 'Not for' with the two alternative tools named for each excluded case. The condition selecting each sibling is spelled out, 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.

Deploy Server

Other Tools