Skip to main content
Glama
edgegap

Edgegap MCP Server

Official
by edgegap
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Add a player to a relay session

edgegap_authorize_relay_user
Idempotent

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.

Instructions

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.

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_ipYesPublic IP of the joining player.
session_idYes

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/5.0
Behavior3/5

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

Annotations already declare openWorldHint, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description usefully adds that a per-player authorization token is returned, but says nothing about what a repeat call for an already-authorized IP does, even though idempotency is asserted.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, zero filler, with the action and the triggering scenario front-loaded before the return value. Nothing redundant with the title or schema.

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 small three-parameter mutation with annotations present, the description covers the action, the scenario, and the returned token (no output schema exists, so this is needed). Remaining gaps are error/repeat-call behavior against a non-existent or already-authorized player.

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?

user_ip and dry_run are fully documented in the schema; session_id has no schema description at all. The description partially compensates by stating the session must already exist and the IP is public, but adds no format or constraint detail. This matches a baseline 3 at 67% coverage.

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 (authorize) plus resource (relay session / player) and scope ('one more player... joining after the session was created'). This cleanly separates it from edgegap_create_relay_session, edgegap_get_relay_session, and edgegap_delete_relay_session in the sibling set.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives a clear usage condition: use it for a player joining after the session already exists, which implies create_relay_session handles players present at creation. It stops short of naming that sibling or stating exclusions such as duplicate authorization of an already-authorized IP.

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