Gopeak vs Ue MCP

A side-by-side look at the Gopeak and Ue MCP MCP servers: transport, auth, tools, quality signals, and the config to install either one in Claude, Cursor, Windsurf or VS Code.

Gopeak logoGopeakGaming · Local subprocess (stdio)GoPeak — The most comprehensive MCP server for Godot Engine. 95+ tools, LSP, DAP, screenshots.67GreatAuth: no auth requiredUe MCP logoUe MCPGaming · Local subprocess (stdio)Complete Unreal Engine development toolkit exposed as MCP tools.63GoodAuth: no auth required

Verdict: choose Gopeak for gaming work as a local process; choose Ue MCP for gaming as a local process. You can also run both side by side in one mcpServers block.

Which MCP server should you choose?

Gopeak logoChoose Gopeak when

  • You need dedicated capabilities in the Gaming domain.
  • You prefer a local stdio subprocess transport.
  • Its auth model fits you: No auth required.
  • You have the keys it needs: GODOT_PATH, GOPEAK_TOOL_PROFILE, MCP_TOOL_PROFILE.
  • You want tools like tool-catalog, project-list, project-info.
Explore Gopeak

Ue MCP logoChoose Ue MCP when

  • You need dedicated capabilities in the Gaming domain.
  • You prefer a local stdio subprocess transport.
  • Its auth model fits you: No auth required.
  • You want tools like tools, flow.
Explore Ue MCP

Feature & specification comparison

Rows where the two servers differ are marked.

SpecGopeak logoGopeakUe MCP logoUe MCP
CategoryGamingGaming
Quality signal67/100 · Great63/100 · Good
Install commandConfirmedConfirmed
TransportLocal subprocess (stdio)Local subprocess (stdio)
AuthNo auth requiredNo auth required
PricingFreeFree
Required env varsGODOT_PATHGOPEAK_TOOL_PROFILEMCP_TOOL_PROFILENone listed
Verified ownerCommunity listingCommunity listing
GitHub stars269448
Directory activity 2 views 0 installs 0 upvotes 0 views 0 installs 0 upvotes
Tools332

Tools & capabilities

Gopeak tools 33

  • tool-catalog[compact alias of tool_catalog] Discover available tools including hidden legacy tools. Use query to search by capability keywords. Results include group categorization (core/dynamic). Matching dynamic groups are auto-activated and become available immediately. Core groups (always visible): core_meta, core_project, core_editor, core_scene, core_script, core_class, core_signal, core_resource, core_export, core_runtime, core_visualizer, core_diagnostics. Dynamic groups (on-demand): scene_advanced, uid, import_export, autoload, signal, runtime, resource, animation, plugin, input, tilemap, audio, navigation, theme_ui, asset_store, testing, dx_tools, intent_tracking, class_advanced, lsp, dap, version_gate.
  • project-list[compact alias of list_projects] Scans a directory for Godot projects (folders containing project.godot). Use to discover projects before using other tools. Returns array of {path, name}.
  • project-info[compact alias of get_project_info] Returns metadata about a Godot project including name, version, main scene, autoloads, and directory structure. Use to understand project before modifying. Requires valid project.godot.
  • project-search[compact alias of search_project] Searches for text or regex patterns across project files. Use to find function usages, variable references, or TODOs. Returns file paths and line numbers.
  • project-setting-get[compact alias of get_project_setting] Reads a value from project.godot settings. Use to check game name, window size, physics settings, etc.
  • project-setting-set[compact alias of set_project_setting] Writes a value to project.godot settings. Use to configure game name, window size, physics, etc.
  • editor-launch[compact alias of launch_editor] Opens the Godot editor GUI for a project. Use when visual inspection or manual editing of scenes/scripts is needed. Opens a new window on the host system. Requires: project directory with project.godot file.
  • editor-run[compact alias of run_project] Launches a Godot project in a new window and captures output. Use to test gameplay or verify script behavior. Runs until stop_project is called. Use get_debug_output to retrieve logs.
  • editor-stop[compact alias of stop_project] Terminates the currently running Godot project process. Use to stop a project started with run_project. No effect if no project is running.
  • editor-debug-output[compact alias of get_debug_output] Retrieves console output and errors from the currently running Godot project. Use after run_project to check logs, errors, and print statements. Returns empty if no project is running.
  • editor-status[compact alias of get_editor_status] Returns the connection status of the Godot Editor Plugin bridge. Use to check if the editor is connected before using scene/resource tools that require the editor plugin.
  • editor-version[compact alias of get_godot_version] Returns the installed Godot engine version string. Use to check compatibility (e.g., Godot 4.4+ features like UID). Returns version like "4.3.stable" or "4.4.dev".
  • +21 more on the listing page

Ue MCP tools 2

  • toolsGateway to every ue-mcp category (micro context mode). Find actions with search, inspect parameters with describe, then invoke with call. Actions: - search: Find actions by keyword or intent; returns category.signature lines. Params: query, limit? (default 20) - list_categories: List every category with a one-line summary. - describe: A category's action signatures a page at a time, or one action's parameter schema. Params: category, method?, offset? - call: Invoke any action. Params: category, method (the action name), args (object of the action's params).
  • flowRun pre-built named sequences for this project. ALWAYS check project(action="get_status") first - its 'flows' field lists what's available. If a flow matches the user's request, run it via flow(action="run", flowName="...") instead of composing the sequence by hand. Config reloads on every call - no restart needed. Actions: - run: Execute a named flow from ue-mcp.yml. Params: flowName, skip? (step names or numbers), params? (runtime options merged into every step's options, highest priority), rollback_on_failure? (invoke inverse tasks in reverse order when a later step fails). A step whose handler reports success:false FAILS the step and stops the run, and the inverses collected up to and including it are what rollback_on_failure unwinds. A step whose failure is EXPECTED says so itself, in the YAML, with ignore_failure: true - the run walks on, and the step is still recorded as failed with its error and its data, marked ignoredFailure. That is how stop, build, start survives an editor that was already stopped, instead of editor(stop_editor) reporting a success it did not achieve. The failing step's OWN inverse, which a few handlers attach after a partial write, is collected like every other: under rollback_on_failure it is replayed FIRST, ahead of the steps before it, so the partial write is undone before they unwind. It arrives verbatim on steps[i].partialWriteRollback, whose replayed flag says whether the runner ran it or it is yours to run, and in that step's error text. A nested flow's steps arrive on steps[i].nestedSteps, reported on the same terms. Returns a summary, every step's data, and the runId. - plan: Show a flow's execution plan without running a step of it. Params: flowName. Returns the ordered plan, and the flow as declared under definition: its description and each step's task or nested flow, options and conditions, with ${steps.N...} references left unresolved. - list: List the flows available to this project, merged from ue-mcp.yml, the user-global config and any loaded plugin. Params: none Step types supported in YAML flows: any MCP action (category.action), nested flows (flow:), and 'shell' for running shell/exec commands. Per-step options: options, when, retries, retryDelay, retryOn, and ignore_failure (record this step's failure and carry on). Example shell step: steps: 1: { task: shell, options: { command: "npm run up:build" } }

Ready-to-paste client configs

Paste either block (or both) into your client config, e.g. claude_desktop_config.json or ~/.cursor/mcp.json. We only show a config when the install command is confirmed.

Gopeak

mcpServers (Claude Desktop / Cursor)
{
  "mcpServers": {
    "gopeak": {
      "command": "npx",
      "args": [
        "-y",
        "gopeak"
      ],
      "env": {
        "GODOT_PATH": "YOUR_GODOT_PATH_HERE",
        "GOPEAK_TOOL_PROFILE": "YOUR_GOPEAK_TOOL_PROFILE_HERE",
        "MCP_TOOL_PROFILE": "YOUR_MCP_TOOL_PROFILE_HERE"
      }
    }
  }
}

Ue MCP

mcpServers (Claude Desktop / Cursor)
{
  "mcpServers": {
    "ue-mcp": {
      "command": "npx",
      "args": [
        "-y",
        "ue-mcp"
      ]
    }
  }
}

Frequently asked questions

Gopeak is categorized under Gaming and uses a local stdio subprocess. Ue MCP belongs to Gaming and uses a local stdio subprocess. Pick Gopeak for gaming work and Ue MCP for gaming.

Copy the mcpServers block from the config section on this page into your client's config (for example claude_desktop_config.json or ~/.cursor/mcp.json), then fully restart the client.

Gopeak is listed as free. Auth: no auth required. Ue MCP is listed as free. Auth: no auth required. If a server needs environment variables such as API keys, define them under the env key in your client's MCP config.

Yes. MCP clients support multiple servers: add gopeak and ue-mcp as separate keys in the same mcpServers object, and your assistant will call tools from either one.

On AllMCPs, Gopeak has a quality signal of 67/100 (Great) with 2 views, 0 installs and 269 GitHub stars. Ue MCP has 63/100 (Good) with 0 views, 0 installs and 448 GitHub stars.