Edgegap MCP Server

Official

by edgegap

Overview Schema Source Related Servers Discussions Admin

TypeScript

Local

Validate a game server Dockerfile and port config

edgegap_validate_server_config

Read-onlyIdempotent

Validates your game server Dockerfile and port/resource settings against Edgegap requirements before building and pushing, catching image, port, and config errors early.

Instructions

Check a game server Dockerfile and the ports/resources you intend to register against what Edgegap requires, BEFORE building and pushing. Catches the failures that otherwise only show up after a build, push, version and deploy: ARM or Windows images (Edgegap runs linux/amd64), Unreal running as root, missing Unity -batchmode -nographics, a server bound to localhost, EXPOSE ports that do not match the version ports, a protocol that does not match the netcode transport, the "latest" tag, and bad CPU/memory ratios. Pass the Dockerfile text (read it from disk first). If there is no Dockerfile yet, call edgegap_generate_dockerfile instead. Makes no API calls.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "edgegap_validate_server_config"
  }
}

Input Schema

Name	Required	Description
`ports`	No	Ports you plan to pass to edgegap_create_app_version.
`engine`	No	Game engine. Detected from the Dockerfile when omitted.
`netcode`	No	Networking transport, to check the port protocol. Known: mirror-kcp, kcp, mirror-telepathy, telepathy, mirror-simpleweb, simpleweb, websocket, fishnet-tugboat, tugboat, netcode-for-gameobjects, ngo, unity-transport, utp, photon-fusion, litenetlib, enet, unreal-netdriver, godot-enet, godot-websocket.
`cpu_units`	No
`memory_mb`	No
`docker_tag`	No
`dockerfile`	No	Full text of the Dockerfile.
`docker_image`	No
`docker_repository`	No

Output Schema

Name	Required	Description	Default
`engine`	No
`errors`	No
`verdict`	No
`warnings`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.12.0Oct 27, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": {},
+  "properties": {
+    "engine": {
+      "type": "string"
+    },
+    "errors": {
+      "items": {
+        "additionalProperties": {},
+        "properties": {
+          "code": {
+            "type": "string"
+          },
+          "fix": {
+            "type": "string"
+          },
+          "line": {
+            "type": "number"
+          },
+          "message": {
+            "type": "string"
+          },
+          "severity": {
+            "type": "string"
+          }
+        },
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "verdict": {
+      "type": "string"
+    },
+    "warnings": {
+      "items": {
+        "additionalProperties": {},
+        "properties": {
+          "code": {
+            "type": "string"
+          },
+          "fix": {
+            "type": "string"
+          },
+          "line": {
+            "type": "number"
+          },
+          "message": {
+            "type": "string"
+          },
+          "severity": {
+            "type": "string"
+          }
+        },
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "type": "object"
+}

Changed1 schema field changedv0.5.2Oct 14, 2026

addedInput schema / properties / ports / items / properties / tls_upgrade

Added value: +{
+  "description": "TLS Upgrade (wss/https) on a WS or HTTP port, for browser clients.",
+  "type": "boolean"
+}

Addedv0.2.0Oct 1, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations declare readOnlyHint=true, openWorldHint=false and idempotentHint=true, and the description reinforces this with 'Makes no API calls', so an agent knows it is a pure local check. Beyond that it enumerates the actual failure classes detected (ARM/Windows images, root Unreal, missing -batchmode -nographics, localhost binding, EXPOSE/port mismatch, protocol vs netcode mismatch, 'latest' tag, bad CPU/memory ratios), which is real behavioral context annotations cannot carry.

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?

The pre-build purpose and the sibling deferral are front-loaded, and the failure list is dense but each item is a concrete check. The long mid-sentence enumeration is information-dense rather than padded, though it could be bulleted for faster scanning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 9-parameter validation tool with an output schema and rich annotations, the description covers timing, alternative routing, side-effect profile and the check catalog. The only real omission is what docker_image/docker_repository contribute to validation, which an agent would have to guess.

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 only 44%, so the description must compensate, and it does for several key inputs: it tells the agent to read the Dockerfile from disk and pass the full text, and it ties ports, protocol and CPU/memory to concrete validations (EXPOSE mismatch, netcode transport, ratios, 'latest' tag → docker_tag). docker_image and docker_repository remain unexplained in both places, keeping this short of a 5.

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 (check/validate) applied to a specific resource pair (Dockerfile text plus the ports/resources to be registered), and frames the timing relative to build/push/deploy. It is clearly distinguishable from the sibling edgegap_generate_dockerfile, which it names and defers to.

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?

Gives an explicit when: run BEFORE building and pushing, because the failures otherwise surface only after build/push/version/deploy. Gives an explicit alternative and its selecting condition: 'If there is no Dockerfile yet, call edgegap_generate_dockerfile instead.' Nothing is left 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