Skip to main content
Glama
edgegap

Edgegap MCP Server

Official
by edgegap
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Create a relay session (host-client games only)

edgegap_create_relay_session

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.

Instructions

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
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.
user_ipsYesPublic IP of each player, host first. Add late joiners with edgegap_authorize_relay_user.
webhook_urlNoCalled when the session is ready.
timeout_secondsNoDefault 30.
wait_until_readyNoPoll until the relay is assigned. Default true.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field 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"
+}
  2. Addedv0.2.0

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only give the openWorld/idempotent/destructive profile; the description adds genuinely new behavioral context: relay sessions are billed while open, the call blocks until ready, the host is created first, and it returns the relay address plus per-player authorization tokens. The security caveats (host can cheat, host latency advantage, match dies if host quits) further explain the operational consequences of choosing this path.

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?

Efficient in substance — every sentence is decision-relevant — but the action itself is deferred behind two long admonition paragraphs, and the 'not the default' warning is repeated in both the opening and the 'Only use this when' sentence. Slightly wordier than needed, though justified by the misuse risk.

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?

With no output schema, the description still explains the return value (relay address + per-player tokens) and the async readiness behavior. It also covers billing, cleanup via edgegap_delete_relay_session, and late-joiner handling, so an agent has everything needed to call and manage the session correctly.

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 description coverage is 100%, so the schema already documents user_ips, webhook_url, timeout_seconds, wait_until_ready, and dry_run. The description reinforces the host-first ordering and mentions per-player tokens but adds no syntax or format detail beyond the schema, so 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?

States a specific verb+resource ('Creates an Edgegap relay session') and immediately distinguishes it from the sibling edgegap_deploy by naming the dedicated-server alternative. It also names edgegap_authorize_relay_user and edgegap_delete_relay_session, so an agent can place it precisely in the relay workflow without opening a 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?

Explicitly states when to use it ('developer has chosen peer-to-peer/host-client', listen-server netcode) and when not ('not the recommended default', 'Never pick it only because it needs no server image'), names the preferred alternative (edgegap_deploy), and adds a fallback instruction to ask first if the netcode hasn't been established.

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