Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
BRIDGE_PORTNoAlias for SUPERBASE_PORT. Port of the bridge. Must be the same for the bridge and the MCP server. Default is 9731.
BRIDGE_TOKENNoAlias for SUPERBASE_TOKEN. Enables token mode. Must be at least 16 characters. Default is none.
SUPERBASE_PORTNoPort of the bridge. Must be the same for the bridge and the MCP server. Alias: BRIDGE_PORT. Default is 9731.
SUPERBASE_TOKENNoEnables token mode. Must be at least 16 characters. Alias: BRIDGE_TOKEN. Default is none.
SUPERBASE_CLIENT_URLNoURL used in the loadstring script, for example a public raw GitHub link. Default is the bridge's /client.lua URL.

Instructions

Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.

Superbase connects you to live Roblox executor sessions on the user's computer. You can read the console and script errors, search and inspect the instance tree, read and search script sources, spy on remote calls, operate the GUI, take screenshots, change properties and run Lua inside the running game.

Connection awareness:

  • Call roblox_status first in every session, and again whenever a tool fails. It actively pings the Roblox client.

  • Every tool result begins with a [Superbase] status line that shows the current connection state.

  • States: connected (all tools work); waiting_for_roblox (the bridge runs but no game is connected); unresponsive (a client is connected but does not answer: the game may be frozen, loading or closing); unknown_client (the client id you passed is not connected); bridge_offline (the bridge is not running and could not be started automatically: the hint says why); token_mismatch (the bridge and this MCP config disagree about the token).

  • The bridge starts by itself when a tool needs it, so the user does not have to run npm start (it stays available for running the bridge by hand). A note in the status line says when that happened. When that note appears, tell the user in plain words that the bridge now runs in the background, that it keeps running until they stop it (on Windows: right-click the Superbase icon in the tray and choose Stop Superbase; anywhere: npm run stop), and that autostart can be turned off with "autostart": false in superbase.config.json. Do not skip this, they have not seen the note unless you say it.

  • After a teleport the Roblox client comes back by itself only when the user has the Superbase loader in the executor's autoexec folder. If the state is waiting_for_roblox right after a teleport, call roblox_status again in a few seconds. If it stays disconnected for a minute or more, ask the user to run the loader again in the new place, or to use npm run autoexec.

  • When the state is waiting_for_roblox, the status line contains a one-line loadstring script. Show it to the user in a code block so they can run it in their executor, then wait for them.

  • When the state is not connected, do not retry in a loop. Tell the user what is missing and wait for them.

Several Roblox windows:

  • Several clients can be connected at once, each with an id such as c1 or c2. list_clients shows them.

  • Every tool that talks to the game accepts a 'client' id. Without it, the client that connected last is used. Pass the id whenever more than one client is connected and the user did not make clear which one they mean.

Working with the game:

  • get_game_info gives an overview. get_hierarchy prints the tree, find_instances searches it (by name, class or a CSS-like selector), inspect_instance reads one instance.

  • Scripts: list_scripts lists them, get_script_source reads one, search_scripts greps through all sources (text, Lua pattern or words mode).

  • remote_spy records RemoteEvent and RemoteFunction calls: start it, let the user (or gui_interact) trigger the action, read the calls with get, then stop it. With block it can also stop calls to chosen remotes from reaching the server (unblock undoes it).

  • gui_interact lists buttons and text boxes, clicks buttons, types into text boxes and triggers click detectors and proximity prompts. screenshot shows what the Roblox window looks like (Windows only).

  • player_info lists the players with position, distance, health and items. character_control teleports the local character or walks it to a position, a player or an instance.

  • stats measures FPS (average, minimum, 1% low), stutters, memory, ping and world size, with short notes on what looks wrong. snapshot saves the state of part of the tree and later reports what was added, removed or changed, which is the way to see the effect of an action.

  • semantic_search finds code by meaning with a local Ollama: index the game once (repeat with offset until done is true), then search with a plain description. It needs Ollama running with the embedding model pulled, and says what is missing. Use search_scripts for exact text.

  • recipes lists and runs small Lua helpers for inspecting the game (a folder of .lua files with a header). Check the list before you write a script for a common inspection task. Recipes are not the place for what the user asks you to build: when the user wants a script (a freecam, an ESP, an auto farm, anything), give the code to the user in your reply, or run it with execute_lua or run_file when they want it running now. Never save it as a recipe unless the user explicitly asks you to save a recipe.

  • Reverse engineering: inspect_code reads the upvalues and constants of a script or of a module function, searches the garbage collector for functions and tables, and lists the handlers connected to a signal. http_spy records the HTTP requests that scripts send (secrets are redacted): start it, let the action happen, read with get. get_script_source, search_scripts and dump results come from a cache in the executor, pass refresh to decompile again.

  • call_instance calls a method, fires a RemoteEvent or RemoteFunction, or fires a signal, with Roblox values written as __type objects. wait_for_instance waits until a path exists, for example after a teleport. run_file runs a .lua file from the user's computer in the game. notify shows a short toast in the Roblox window, for example when a long task is finished.

  • To check the effect of an action, use execute_lua with capture_logs, or wait_for_log to wait for a specific console line.

  • Logs and errors are stored by the bridge, so get_logs and get_errors still work while waiting_for_roblox.

Selector syntax for find_instances: Type, #Name, [property=value], descendants separated by a space, direct children with >. Examples: RemoteEvent, Model > Part, Part[Anchored=false], TextButton#Play, Frame TextLabel[Text*='coins']. Operators: = != *= (contains) ^= (starts with) $= (ends with) < <= > >=.

Safety:

  • execute_lua, run_file, call_instance, set_property, gui_interact (click, set_text, trigger), remote_spy and http_spy change or observe the running game with the executor's full permissions. Only do what the user asked for, and explain anything that changes the game or the user's files before you do it. character_control moves the player and recipes (save) writes a file in the recipes folder, so treat them the same way.

  • If the bridge runs on another computer (the host setting), it is never started automatically: tell the user to start it there.

  • Instance paths are dotted and start at game. Instance names that contain a dot cannot be addressed.

Capabilities

Features and capabilities supported by this server

Protocol revision2025-11-25

CapabilityDetails
tools
{}
prompts
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
roblox_statusA

Check whether Superbase is connected to a running Roblox game. Actively pings the Roblox client and returns the connection state (connected, waiting_for_roblox, unresponsive, unknown_client, bridge_offline or token_mismatch), the connected clients, the place, the executor, the latency and the number of stored logs and errors. While waiting_for_roblox it also returns the loadstring script the user must run. Call this first.

list_clientsA

List every Roblox client connected to the bridge (several windows or accounts can be connected at once): id, player, place, server, executor, latency and which one is the default. Pass an id as the 'client' argument of the other tools to pick one.

get_game_infoA

Get an overview of the running game: place name and creator, server job id, the local player, the player list and performance (physics FPS, memory, ping). Requires the connected state.

get_logsA

Read recent console output captured from the Roblox executor. The newest entries come last, and the result has a now timestamp you can pass as since next time. Works while waiting_for_roblox because the bridge stores the logs.

get_errorsA

Read recent script errors captured from the Roblox executor, including the stack trace and the script path. Works while waiting_for_roblox because the bridge stores the errors.

wait_for_logA

Wait until a new console line (or script error) that contains the given text appears, then return it. Use it after an action to confirm its effect. Returns matched false when the timeout passes. Requires the bridge, and only sees lines that arrive after the call starts.

execute_luaA

Run Lua code inside the connected Roblox executor. Returns the serialized return values, or the error with a traceback. Set capture_logs to also get the console lines and script errors that appeared while it ran. Use timeout_ms for code that takes long. The code runs with the executor's full permissions, so only run code the user asked for. Requires the connected state.

inspect_instanceA

Inspect a Roblox Instance by dotted path (for example game.Workspace.Map.Part). Returns its class, selected properties and children. Requires the connected state.

get_hierarchyA

Print the instance tree under a path as an indented outline (name and class per line), like the Explorer panel. Use it to get to know a game quickly. Limit it with depth (default 3), max_nodes and max_children, or show only the branches that lead to a class with class_name. Requires the connected state.

find_instancesA

Search the instance tree. Use a CSS-like selector (for example Model > Part[Anchored=false], TextButton#Play, Frame TextLabel[Text*='coins'], RemoteEvent) or the simple name and class_name filters. Returns the full path and class of each match, optionally with property values, and whether the result list was cut off. Requires the connected state.

list_scriptsA

List the Scripts, LocalScripts and ModuleScripts of the game with their path, class and whether they are disabled. With include_hidden it also finds scripts that are not in the tree (nil parented instances, loaded modules, running scripts) when the executor supports it. Requires the connected state.

get_script_sourceA

Read the source code of a Script, LocalScript or ModuleScript by dotted path. It uses the executor's decompile when available and falls back to the Source property. Decompiled sources are cached in the executor (fromCache in the result, refresh decompiles again). Long sources are cut at max_chars. Requires the connected state.

search_scriptsA

Search the source code of the game's scripts, like grep. Modes: text (exact text, default), pattern (a Lua pattern, always case sensitive) and words (every word must appear, scripts are ranked by how often they match). It decompiles the scripts, which can be slow (results are cached in the executor, set refresh to decompile again), so it stops after budget_seconds and reports how many scripts it searched. Narrow it with root or class_name for speed. Requires the connected state.

semantic_searchA

Find code by what it does, not by exact words, with embeddings from a local Ollama (model embeddinggemma by default; nothing leaves the computer). Actions: index (read the scripts of the connected game and build the index; big games take several calls, repeat with offset set to the returned nextOffset until done is true), search (query, optional k, path_contains, place_id: returns the closest code chunks with their path and lines), status (what is indexed) and clear (delete the index of place_id, or all). Search and status do not need the game. Needs Ollama running with the model pulled (ollama pull embeddinggemma). For exact text use search_scripts instead.

remote_spyA

Record the RemoteEvent:FireServer and RemoteFunction:InvokeServer calls the game's own scripts make, with their arguments and the calling script. Actions: start (begin recording, optional only, ignore, max_calls, include_own), get (read recorded calls, optional since_id, contains, remote, limit), stop, clear and status. Typical use: start, make the action happen (ask the user or use gui_interact), then get. block (remotes: names or full paths) drops the game's calls to those remotes before they reach the server, even without recording, and unblock releases them (all when remotes is empty). Blocking changes how the game behaves, so only do it when the user asked for it and tell them which remotes are blocked. Recording and blocking need hookmetamethod in the executor and stay installed until the game is left. Requires the connected state.

inspect_codeA

Look inside code that is running in the game, for reverse engineering. Actions: upvalues and constants (path of a script; for a ModuleScript also function_name to look at one function of the module), gc (search the garbage collector for functions by name_contains or has_constant, or for tables by has_key; at least one filter is required) and connections (path of an instance and the name of one of its signals: lists the handlers that are connected, with the function name, line, source and owning script). Needs the matching executor functions (getscriptclosure, getupvalues, getconstants, getgc, getconnections) and says which one is missing. Only reads. Requires the connected state.

call_instanceA

Act on the running game directly. Actions: method (call a method of the instance at path, for example FindFirstChild or Destroy, with args), fire_remote (RemoteEvent:FireServer or RemoteFunction:InvokeServer with args, returns the answer of an InvokeServer) and fire_signal (firesignal on one of its events, for example MouseButton1Click). Roblox values in args are written as objects with __type: {"__type":"Vector3","x":1,"y":2,"z":3}, Vector2, Color3 (r, g, b from 0 to 255), CFrame (x, y, z), Enum ({"__type":"Enum","value":"Enum.Material.Neon"}) and Instance ({"__type":"Instance","path":"game.Workspace.Part"}). This changes the running game and can have effects on the server, so only do it when the user asked for it. Requires the connected state.

wait_for_instanceA

Wait until the instance at a dotted path exists (and optionally is of a class), for example after a teleport or while a map loads. Returns found true with the path, or found false with the segment that is still missing after the timeout. Requires the connected state.

http_spyA

Record the HTTP requests that scripts send: the executor's request functions (request, http_request, syn.request, ...) and game:HttpGet, HttpPost and HttpService calls. Each entry has the method, address, headers, body, status and answer. It sees the requests of the game and of any other script in the executor, but not the traffic between Superbase and its bridge. Authorization, cookie and token values (also in addresses) and the Roblox account cookie are replaced with before they are stored, and bodies are cut at max_body. Actions: start (optional max_calls, max_body, include_bodies, url_contains), get (optional since_id, url_contains, method, limit), stop, clear and status. Typical use: start, make the action happen, then get. Needs hookfunction or hookmetamethod in the executor and stays installed until the game is left. Requires the connected state.

notifyA

Show a small notification (toast) in the corner of the Roblox window, for example to tell the user that a long task is done while they are playing. Keep it short. Needs a Superbase client from version 1.4.0 and notifications switched on in the client settings. Requires the connected state.

run_fileA

Read a .lua, .luau or .txt file from this computer and run it in the connected Roblox executor, like execute_lua but without pasting the code. The path is on the computer that runs the Superbase MCP server (absolute, or relative to its working folder; ~ is the home folder). Files up to 500 KB. The code runs with the executor's full permissions, so only run files the user asked for. Requires the connected state.

gui_interactA

Look at and operate the game's interface. Actions: list (buttons and text boxes with text, visibility and position; default root is the player's PlayerGui), click (press a button: its own events by default, or a real mouse click with mode mouse), set_text (fill a text box, optionally press Enter with submit) and trigger (fire a ClickDetector or ProximityPrompt, given directly or found inside the part or model). Changes the running game. Requires the connected state.

screenshotA

Take a screenshot of the Roblox window and return it as an image, so you can see what the player sees. It captures the real window on the computer where the bridge runs (Windows only), so the window must be visible: not minimized and not covered by another window. It asks Windows to draw the Roblox window itself, so other windows in front of it do not end up in the picture and nothing is raised. If that gives no usable picture, it falls back to copying the screen area of the window: with focus true (default) Roblox is raised for a moment and your previous window is put back, with focus false the screen is copied as it is. Does not need the executor connection.

set_propertyA

Set a property on an instance in the running game (on the client, so it only replicates where Roblox allows it). The value is given as JSON text in value_json: a string, number or boolean (for example "42" or ""Hello""), or an object with a type field: {"type":"Vector3","x":1,"y":2,"z":3}, {"type":"Vector2","x":1,"y":2}, {"type":"Color3","r":255,"g":0,"b":0}, {"type":"Enum","enum":"Material","name":"Neon"} or {"type":"Instance","path":"game.Workspace.Part"}. Returns the old and new value. Requires the connected state.

player_infoA

Look at the players in the server. action list (default) returns every player with team, character position, distance to the local player and health; details true adds walk speed, jump, state, equipped tools, backpack, leaderstats and attributes. action character returns all of that for one player (player: name, display name or user id; default the local player). Requires the connected state.

character_controlA

Move the local player's character. action teleport puts it at the target at once; action walk_to makes it walk there with the humanoid (it stops when it arrives, gets stuck or the timeout passes). The target is one of: position ({x,y,z}), player (another player's name, display name or user id) or path (a dotted path to a part or model). Near a player or instance the character lands offset_y studs above it (default 3). Teleporting can trigger anti-cheat in some games, so only do it when the user asked. Requires the connected state.

statsA

Measure how the game performs right now: it samples the frames for a moment (average FPS, minimum FPS, the 1% low, frame time, stutters longer than 50 ms), and reports physics FPS, memory, ping, network traffic, instance and part counts, plus short notes that say what looks wrong. memory detail adds the memory per category. The game window must be visible, because Roblox does not render frames for a minimized window. Requires the connected state.

snapshotA

Save the state of part of the game and later see exactly what changed. action take records the instances under a path (names, classes and the properties that matter for each class, or the ones you list) in a named slot; action diff compares the slot with the game as it is now and lists what was added, removed and changed (property, before, after); action list shows the slots; action delete removes one. Use it around an action: take, let the user do something or trigger it with gui_interact, then diff. Snapshots live in the executor's memory, at most 10 slots, and are gone when the game is left. Requires the connected state.

recipesA

Reusable Lua scripts kept as .lua files in the recipes folder of Superbase (the user can also run them from the dashboard). action list shows the recipes with their description and arguments; action run executes one in the game (name, and args for the recipe, available there as the table args); action save writes a new recipe (name, code, and a title, description and usage line for its header; overwrite true replaces an existing one). Recipe names are lowercase letters, digits, - and _. Recipes are small helpers for inspecting the game, not storage for scripts that the user asks you to make: when the user wants a script (a freecam, an ESP, an auto farm, anything they want to keep or run), give the code to the user in your reply and do not save it here. Use save only when the user explicitly asks you to save a recipe. Recipes run with the executor's full permissions like execute_lua, so read a recipe's code before you run one you did not write. Sharing: preview_import downloads a recipe from a link (https only; GitHub files and gists, GitLab files; at most 100 KB) and shows its code and header without saving anything. Show that code to the user and say what it does. import saves it into the recipes folder, and only with confirm true after the user has agreed; it never runs the recipe. Imported code comes from the internet and is untrusted. run needs the connected state, the other actions do not.

clear_logsA

Permanently delete the console logs and script errors that the bridge has stored, for all clients or only for one. The bridge keeps them in memory only, so a cleared entry cannot be recovered. Nothing else is touched: the Roblox console, snapshots, recipes and the game itself stay as they are. Use it to get a clean slate right before you reproduce a problem, so that get_logs, get_errors and wait_for_log only show new lines. Do not use it to hide old output you may still need: read it with get_logs or get_errors first. It does not need a running game, and clearing an empty store is harmless. Returns { cleared: true, client } where client is null when everything was cleared.

Prompts

Interactive templates invoked by user choice

NameDescription
diagnoseCheck the connection, read the errors and logs, and report what looks wrong in the running game.
find-codeLocate the scripts and lines that implement a feature, by meaning and by exact text.
explain-gameBuild an overview of the game's structure, scripts and remotes.
trace-remoteRecord the remote calls the game makes during an action and work out what they mean.
performance-checkMeasure FPS, stutters, memory and ping, and look for the scripts or instances that cause trouble.
why-errorFind the cause of a script error, from the latest error or from the text you give.

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A3.9/5.0

Scored across 30 tools

Disambiguation4/5

Each tool targets a distinct area (execution, instance inspection, script search, spying, GUI, performance, snapshots), and the descriptions actively cross-reference each other (semantic_search defers to search_scripts, run_file is described as execute_lua from a file). The only real overlaps are among the code-execution tools (execute_lua, run_file, recipes.run) and the log trio (get_logs, get_errors, wait_for_log), but the descriptions make the boundaries clear enough to choose correctly.

Naming Consistency3/5

Most tools follow a verb_noun snake_case pattern (get_logs, list_scripts, find_instances, wait_for_instance, set_property), but a large minority are bare nouns or noun_verb hybrids (recipes, snapshot, stats, notify, screenshot, roblox_status, http_spy, remote_spy). Conventions are mixed, yet every name remains readable and domain-indicative.

Tool Count3/5

30 tools is heavy and several are multi-action bundles (recipes, snapshot, remote_spy, http_spy, gui_interact, player_info, call_instance), so the set is at the upper limit even for this broad domain. Nothing feels truly redundant, but a few thin tools (notify, clear_logs, wait_for_log) could be folded into siblings to slim the surface.

Completeness4/5

Coverage is genuinely broad: connection state, execution, script/instance discovery, code introspection, remote/HTTP interception, GUI interaction, screenshots, performance and snapshot diffing all exist as lifecycle-complete families. Minor gaps remain, such as browsing or reading local files (only run_file executes them) and no way to abort a runaway Lua execution.

Maintenance

ActivityMaintained
ResponsivenessOutdated data