Edgegap MCP Server
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| EDGEGAP_API_TOKEN | No | API token. Optional — omit it and the developer is asked at first use. The `token ` prefix is added for you. | |
| EDGEGAP_READ_ONLY | No | Set to `1` and the five mutating tools are never registered. The agent cannot see them, so it cannot be talked into calling them. | 0 |
| EDGEGAP_TIMEOUT_MS | No | Per-request HTTP timeout. | 30000 |
| EDGEGAP_APP_ALLOWLIST | No | Comma-separated application names. When set, every tool refuses to touch anything else. | |
| EDGEGAP_MAX_DURATION_MINUTES | No | Ceiling on `max_duration` the agent may set on a version. Caps runaway cost from an unattended agent. | 60 |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| edgegap_list_appsA | 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. |
| edgegap_create_appA | 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. |
| edgegap_list_app_versionsA | 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. |
| edgegap_create_app_versionA | 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. 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. |
| edgegap_deployA | Start one containerized instance of an application version, placed near the players you specify. 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. |
| edgegap_get_deploymentA | 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. |
| edgegap_wait_for_deploymentA | 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. |
| edgegap_list_deploymentsA | List active deployments, optionally filtered. Use this to find deployments left running from earlier sessions before starting new ones — orphaned servers cost money. |
| edgegap_stop_deploymentA | 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. |
| edgegap_get_deployment_logsA | 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. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 10 tools
Each tool targets a distinct resource and action: apps, versions, deployments, and logs. The only close pair is get_deployment vs wait_for_deployment, but their descriptions explicitly distinguish one-shot status read from polling helper, so there is no real ambiguity.
All tools share the edgegap_ prefix and mostly follow a verb_noun pattern (list_deployments, create_app, get_deployment_logs). Minor deviations like the bare verb 'deploy' and 'wait_for_deployment' are still predictable and readable.
With 10 tools covering apps, versions, and deployments, the count is well-scoped for the domain. Each tool maps to a clear lifecycle step, and no tool feels redundant.
The core workflow is fully covered: create/list apps, create/list versions, deploy, wait, get status, logs, and stop. Missing update/delete for apps/versions and bulk stop are minor gaps, but agents can complete typical tasks without dead ends.