Skip to main content
Glama
ProjectMakersDE

horizOn MCP Server

Official
by ProjectMakersDE
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Get Remote Config

horizon_get_remote_config
Read-onlyIdempotent

Reads one remote config value by key as a string, so a game can check a single feature flag or balance value; unknown keys return found: false.

Instructions

Reads one remote config value by key (a feature flag or balance value set in the horizOn dashboard) as a string. Use when: the game needs a single value, for example to check one feature flag. Not for: loading many values at start (use horizon_get_all_remote_configs, one request instead of many). Side effects: None (read only). Returns: {configKey, configValue, found}. Values are always strings: parse numbers and booleans yourself. An unknown key is not an error: found is false and configValue null, so fall back to a default. Errors: 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
keyYesConfig key exactly as defined in the dashboard, case-sensitive, for example 'max_lives' (max 256 characters)

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
foundNo
configKeyNo
configValueNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv1.6.0
    • changedInput schema / properties / key / description
      Previous value: -"Configuration key as defined in the dashboard, case-sensitive (max 256 characters)"New value: +"Config key exactly as defined in the dashboard, case-sensitive, for example 'max_lives' (max 256 characters)"
    • addedInput schema / properties / key / minLength
      Added value: +1
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": {},
+  "properties": {
+    "configKey": {
+      "anyOf": [
+        {
+          "description": "The requested key",
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ]
+    },
+    "configValue": {
+      "anyOf": [
+        {
+          "description": "The value as a string, null when not found",
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ]
+    },
+    "found": {
+      "anyOf": [
+        {
+          "description": "false when the key does not exist",
+          "type": "boolean"
+        },
+        {
+          "type": "null"
+        }
+      ]
+    }
+  },
+  "type": "object"
+}
  2. Changed1 schema field changedv1.5.5
    • changedInput schema / properties / key / description
      Previous value: -"Configuration key (max 256 characters)"New value: +"Configuration key as defined in the dashboard, case-sensitive (max 256 characters)"
  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?

Annotations already declare readOnly/idempotent/non-destructive, but the description goes well beyond them: unknown keys are not errors (found=false, configValue=null, fall back to a default), all values are strings requiring manual parsing, and error semantics include HORIZON_API_KEY requirement, 401 diagnosis via horizon_test_connection, and 429 per-minute rate limit with a wait-and-retry instruction.

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?

Dense but organized under labeled sections (Use when / Not for / Side effects / Returns / Errors), with the core purpose front-loaded in the opening sentence. Every line carries actionable information; none is filler.

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 one-parameter read with an output schema, the description supplies everything an agent needs: auth requirement, verbatim error taxonomy, string-typed return caveat, and default-fallback behavior on missing keys. Nothing material is omitted.

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% and the single 'key' parameter is fully documented in the schema (case-sensitivity, 256 char max, example). The description adds only 'by key', contributing nothing beyond the structured field, so the 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?

Specific verb+resource ('Reads one remote config value by key') with scope stated as a single value, and it explicitly contrasts with the sibling horizon_get_all_remote_configs. An agent can distinguish these two tools without opening either 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?

Explicit 'Use when' (single value / check one feature flag) and 'Not for' (loading many values at start → use horizon_get_all_remote_configs, one request instead of many), naming the exact alternative and the condition that selects it.

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