Skip to main content
Glama
Sign In
Edgegap MCP Server

Edgegap MCP Server

Official
by edgegap
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

List the Edgegap agent skills

edgegap_list_skills
Read-onlyIdempotent

Lists Edgegap agent skills with step-by-step multiplayer game workflows, templates, engine/netcode/backend details, and known pitfalls; also indicates if a GitHub skills pack update exists.

Instructions

List the Edgegap agent skills: tested, step-by-step workflows for getting a multiplayer game online on Edgegap, with templates (Dockerfiles, matchmaker configs, Unity C# and Unreal C++ drop-ins) and known pitfalls. Each entry says which engine, netcode or backend it is for, and the server instructions map projects to skills. Before working on a game project, load the matching skill with edgegap_get_skill; "edgegap" covers any other engine and routes to the rest. Also says whether a newer skills pack is on GitHub (reads one version number, no Edgegap API call).

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "edgegap_list_skills"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.5.2

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/openWorld, but the description adds meaningful detail beyond them: it discloses that the GitHub version check 'reads one version number, no Edgegap API call', which clarifies the openWorld behavior and reassures the agent no Edgegap-side side effects occur. It stops short of describing ordering or result size, so not a full 5.

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?

Three tight sentences, front-loaded with the purpose and followed by the routing guidance and the version-check note. Dense with useful detail, though the final parenthetical about GitHub is slightly tacked-on rather than integrated into the flow.

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?

With no output schema, the description carries the return-value burden and does it: it explains that each entry states engine/netcode/backend, and that server instructions map projects to skills. Nothing an agent needs in order to decide to call it and interpret the result is missing, though the shape of the GitHub version-check result is only lightly described.

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?

The tool takes zero parameters, so the baseline is 4. The description adds no parameter information because none is needed, and the empty schema is fully consistent with the described behavior.

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 ('List the Edgegap agent skills') and immediately defines what a skill is (tested step-by-step workflows with templates and pitfalls). It also explicitly contrasts itself with the sibling edgegap_get_skill, which loads a single skill, so an agent can choose between them without opening the 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?

Gives an explicit trigger ('Before working on a game project, load the matching skill with edgegap_get_skill') and names the fallback ('edgegap' covers any other engine and routes to the rest). It also flags the secondary purpose of reporting whether a newer skills pack exists on GitHub, so the agent knows both reasons to call it.

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