List the applications in the Edgegap organization. Start here before creating or deploying anything, so you reuse an existing application instead of making a duplicate. An "application" groups versions of one game server.

Create a new application to hold game server versions. Only call this after edgegap_list_apps confirms no suitable application exists. Creating an application does not deploy anything — follow with edgegap_create_app_version.

List the versions under an application, with their container image and resource settings. Use this to find the version name to deploy, or to copy settings from a working version when creating a new one.

Register a container image as a deployable version of an application. The image must already be pushed to a registry that Edgegap can pull from (see edgegap_get_registry_credentials and edgegap_list_registry_tags). Resource units: 1024 cpu units = 1 vCPU; memory_mb must be at least 256 and at most double the cpu units. Set verify_image true on the first version so a bad image fails here rather than at deploy time. Avoid the "latest" docker tag — use a build ID so deployments are reproducible.

Start one authoritative dedicated game server from an application version, placed near the players you specify. This is the recommended way to host a multiplayer match: the server owns the game state, so no player hosts it. Returns immediately with a request_id; the server is still starting and has no connection details yet. Follow this call with edgegap_wait_for_deployment to get the address players connect to. Always stop deployments you started for testing.

Read the current status of one deployment, including connection address and ports once it is ready. For a deployment you just created, prefer edgegap_wait_for_deployment — it polls for you instead of making you call this in a loop.

Poll a deployment until it is ready, errors, or the timeout expires, then return the connection details. This is the tool to call right after edgegap_deploy. Do not build your own polling loop — this handles backoff and reports the container error detail if the server fails to start.

List active deployments, optionally filtered and sorted. Use this to find deployments left running from earlier sessions before starting new ones — orphaned servers cost money. Filter by status, application, version, tags, request_id, created_at, fleet_name or host_name, e.g. [{field:"application",operator:"eq",value:"my-game"},{field:"status",operator:"eq",value:"ready"}]. Operators: eq and neq on every field except created_at (eq, gte, lte); in and nin with an array value on request_id, tags, application, version, fleet_name, host_name; ilike with % wildcards on fleet_name and host_name. At most one filter per field. Sort by created_at or available_session_sockets.

Gracefully stop one deployment by request_id, sending SIGTERM to the container. Stop every deployment you started for testing before ending your task. This tool stops exactly one deployment; bulk stop is deliberately not exposed.

Retrieve stdout/stderr and crash output for a deployment. Call this whenever a deployment errors or a server exits unexpectedly — the crash exit code usually identifies the problem faster than redeploying does. Logs for stopped deployments are only retained if Endpoint Storage was configured on the version beforehand.

Write a Dockerfile for this project's headless game server build, ready for Edgegap: linux/amd64 base, the build folder copied in, the binary made executable, the right headless flags (Unity -batchmode -nographics, Godot --headless), a non-root user where the engine needs it (Unreal refuses root), CRLF fixes for start scripts, and EXPOSE lines matching the ports. Call this when the project has no Dockerfile, before building anything. Look at the build output first so you can pass the real build folder, binary name and port; anything you omit is assumed and listed under assumptions, which you must confirm with the developer or the project files. Write the result to Dockerfile, then build. The output is checked against edgegap_validate_server_config before it is returned. Makes no API calls.

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.

Return the registry URL, project, username and token for this organization's private Edgegap container registry (registry.edgegap.com), plus the exact docker login, build and push commands for your image. Use this when the server image is not in a registry yet — no Docker Hub account needed. Provisions the registry project on first use. The token is registry-scoped (push/pull images in this project), not the org API token: pass it to docker login via --password-stdin, never as a command-line argument, and do not write it into files. Call edgegap_validate_server_config before building.

List the tags pushed for one image in this organization's Edgegap container registry, with push time and size. Call it after docker push to confirm the tag landed before edgegap_create_app_version, which otherwise fails later with an image-pull error.

A relay is NOT a game server and is not the recommended default — for a multiplayer match, deploy an authoritative dedicated server with edgegap_deploy instead. A relay only forwards traffic between players while one player's game acts as host and owns the game state: the host can cheat and has a latency advantage, the host's PC and connection cap the match, and the match ends if the host quits. Only use this when the developer has chosen peer-to-peer/host-client, or the netcode is already a listen server and a dedicated server is not an option; if that has not been established, ask first. Never pick it only because it needs no server image. Creates an Edgegap relay session for every player's public IP, host first, waits until it is ready, and returns the relay address plus per-player authorization tokens for the relay transport. Relay sessions are billed while open: delete test sessions with edgegap_delete_relay_session when finished.

Read one relay session: whether it is ready, the relay address and ports, and each authorized player with their authorization token. edgegap_create_relay_session already waits for readiness; use this to re-read a session or one created with wait_until_ready false.

Authorize one more player (by public IP) on an existing relay session, for a player joining after the session was created. Returns that player's authorization token.

Close one relay session. Connected players lose their relay connection. Delete every session you created for testing before ending your task.

Generate a ready-to-upload Edgegap matchmaker JSON configuration with one profile: team count and size, optional latency rule, and optional expansions that relax the rules the longer a player waits. Checks the referenced application version exists and has ports. Edgegap has no API for creating a matchmaker, so this tool does NOT create one: save the returned config to a file (e.g. matchmaker-config.json) and have the developer upload it on the Matchmaker page of the dashboard. The matchmaker starts an authoritative dedicated server for each match, which is the recommended setup for multiplayer games.