Skip to main content
Glama

Deploy a game server

edgegap_deploy

Starts a dedicated authoritative game server from an application version near specified players and returns a request_id; then call edgegap_wait_for_deployment for connection details.

Instructions

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. Every deployment is tagged "edgegap-mcp" in addition to any tags you pass, so edgegap_list_deployments with only_agent_deployments: true finds them all. Runs until stopped or until the version's max_duration, which the result reports. Refused, with nothing sent, if the API token appears in an env var or tag, if the version uses the "latest" docker tag, or when too many agent deployments are already running (EDGEGAP_MAX_AGENT_DEPLOYMENTS, default 5): stop finished ones first. Also refused when the version's max_duration is unlimited or above EDGEGAP_MAX_DURATION_MINUTES, unless allow_long_running is true (ask the developer first), and on the local server after EDGEGAP_MAX_DEPLOYS_PER_RUN deploys (default 20). Env vars named like secrets are hidden in the dashboard. Optional: webhooks Edgegap calls when the server is ready, errors or ends (instead of polling), require_cached_locations for faster starts, and private_host_ids to place it on your private fleet first.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "application": "<application>",
      "version": "<version>",
      "users": "<users>"
    },
    "name": "edgegap_deploy"
  }
}

Input Schema

NameRequiredDescriptionDefault
envNoEnvironment variables for this deployment only. Values are never echoed back.
tagsNoExtra tags for filtering later, e.g. ["agent-test"]. "edgegap-mcp" is always added.
usersYesWhere the players are. Exactly one of these two is required.
dry_runNoShow the exact request (method, host, path, body) with secrets masked, and send nothing. Local checks still run. Use it to confirm a billable or destructive call before making it.
versionYesVersion name within the application.
cpu_unitsNoOverride the version's CPU for this deployment only, with memory_mb. 1024 = 1 vCPU.
memory_mbNoOverride the version's memory for this deployment only, with cpu_units. At most 2x cpu_units.
applicationYesApplication name.
private_host_idsNoPrivate fleet host IDs to try first, in order (from edgegap_list_fleet_hosts); Edgegap overflows to its cloud when they are full. Omit for a normal cloud deployment.
webhook_on_errorNohttps URL Edgegap POSTs to when the deployment fails.
webhook_on_readyNohttps URL Edgegap POSTs to when the server is ready.
allow_long_runningNoDeploy even though the version's max_duration is unlimited or above EDGEGAP_MAX_DURATION_MINUTES. Only after the developer agreed: the server bills until it is stopped or that limit.
webhook_on_terminatedNohttps URL Edgegap POSTs to when the deployment ends.
require_cached_locationsNoOnly place it where the image is already cached: starts faster, fewer places to choose from. Needs force_cache on the version (edgegap_update_app_version); without it the API refuses the deploy.

Output Schema

NameRequiredDescriptionDefault
tagsNo
statusNo
warningNo
auto_stopNo
next_stepNo
resourcesNo
request_idNo
auto_stop_after_minutesNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv0.15.1
    • addedInput schema / properties / allow_long_running
      Added value: +{
      +  "description": "Deploy even though the version's max_duration is unlimited or above EDGEGAP_MAX_DURATION_MINUTES. Only after the developer agreed: the server bills until it is stopped or that limit.",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / private_host_ids
      Added value: +{
      +  "description": "Private fleet host IDs to try first, in order (from edgegap_list_fleet_hosts); Edgegap overflows to its cloud when they are full. Omit for a normal cloud deployment.",
      +  "items": {
      +    "minLength": 1,
      +    "type": "string"
      +  },
      +  "minItems": 1,
      +  "type": "array"
      +}
    • addedInput schema / properties / require_cached_locations
      Added value: +{
      +  "description": "Only place it where the image is already cached: starts faster, fewer places to choose from. Needs force_cache on the version (edgegap_update_app_version); without it the API refuses the deploy.",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / webhook_on_error
      Added value: +{
      +  "description": "https URL Edgegap POSTs to when the deployment fails.",
      +  "type": "string"
      +}
    • addedInput schema / properties / webhook_on_ready
      Added value: +{
      +  "description": "https URL Edgegap POSTs to when the server is ready.",
      +  "type": "string"
      +}
    • addedInput schema / properties / webhook_on_terminated
      Added value: +{
      +  "description": "https URL Edgegap POSTs to when the deployment ends.",
      +  "type": "string"
      +}
  2. Changed3 schema fields changedv0.12.0
    • changedInput schema / properties / cpu_units / description
      Previous value: -"Override the version CPU (with memory_mb). Not in the published v2 spec, so the API may ignore it; a version with the size you need is the reliable way."New value: +"Override the version's CPU for this deployment only, with memory_mb. 1024 = 1 vCPU."
    • changedInput schema / properties / memory_mb / description
      Previous value: -"Override the version memory (with cpu_units). Same caveat as cpu_units."New value: +"Override the version's memory for this deployment only, with cpu_units. At most 2x cpu_units."
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "$schema": "http://json-schema.org/draft-07/schema#",
      +  "additionalProperties": {},
      +  "properties": {
      +    "auto_stop": {
      +      "type": "string"
      +    },
      +    "auto_stop_after_minutes": {
      +      "type": "number"
      +    },
      +    "next_step": {
      +      "type": "string"
      +    },
      +    "request_id": {
      +      "type": "string"
      +    },
      +    "resources": {
      +      "additionalProperties": {},
      +      "properties": {
      +        "cpu_units": {
      +          "type": "number"
      +        },
      +        "memory_mib": {
      +          "type": "number"
      +        }
      +      },
      +      "type": "object"
      +    },
      +    "status": {
      +      "type": "string"
      +    },
      +    "tags": {
      +      "items": {
      +        "type": "string"
      +      },
      +      "type": "array"
      +    },
      +    "warning": {
      +      "type": "string"
      +    }
      +  },
      +  "type": "object"
      +}
  3. Changed2 schema fields changedv0.7.1
    • changedInput schema / properties / cpu_units / description
      Previous value: -"Override the version CPU."New value: +"Override the version CPU (with memory_mb). Not in the published v2 spec, so the API may ignore it; a version with the size you need is the reliable way."
    • changedInput schema / properties / memory_mb / description
      Previous value: -"Override the version memory."New value: +"Override the version memory (with cpu_units). Same caveat as cpu_units."
  4. Changed5 schema fields changedv0.5.2
    • addedInput schema / properties / dry_run
      Added value: +{
      +  "description": "Show the exact request (method, host, path, body) with secrets masked, and send nothing. Local checks still run. Use it to confirm a billable or destructive call before making it.",
      +  "type": "boolean"
      +}
    • changedInput schema / properties / env / description
      Previous value: -"Environment variables for this deployment only."New value: +"Environment variables for this deployment only. Values are never echoed back."
    • changedInput schema / properties / tags / description
      Previous value: -"Tags for filtering later, e.g. [\"agent-test\"]. Recommended."New value: +"Extra tags for filtering later, e.g. [\"agent-test\"]. \"edgegap-mcp\" is always added."
    • addedInput schema / properties / tags / items / maxLength
      Added value: +40
    • addedInput schema / properties / tags / items / minLength
      Added value: +1
  5. First observedv0.1.2

TDQS

A4.8/5.0
Behavior5/5

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

Goes well beyond the annotations: discloses the async return (request_id, no connection details yet), the auto 'edgegap-mcp' tag, lifecycle (runs until stopped or max_duration), billing implications, secret-env-var hiding, and multiple refusal conditions (token in env, 'latest' docker tag, concurrent-deploy caps, max_duration limits, local per-run cap). This is unusually rich behavioral context.

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?

Front-loads purpose and the async/next-step behavior before restrictions. It is dense and long, but for a 14-parameter tool with many guardrails most sentences earn their place; a slight trim of the restriction run-on would help.

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?

Output schema exists, so it needn't explain return structure, and the description still covers the immediate return (request_id) and next-step tool. Given complexity, annotations, and schema richness, nothing critical is missing for correct invocation.

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 100% so the schema already documents all 14 params, but the description adds real meaning: webhooks as a polling alternative, require_cached_locations for faster starts, private_host_ids placement order, and secret-env-var hiding. It complements rather than repeats the schema.

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 ('Start one authoritative dedicated game server from an application version') and clarifies placement near specified players. The distinction from hosting-vs-player-hosted is clear, and it is easy to tell apart from relay/session siblings.

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?

Explicitly frames this as 'the recommended way to host a multiplayer match' and directs the next step ('Follow this call with edgegap_wait_for_deployment'). It also adds operational guidance ('Always stop deployments you started for testing') and names the tool that finds these deployments.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.