Skip to main content
Glama
okenjioxx

Roblox Executor MCP Server

by okenjioxx
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Inventory every remote in a subtree of the DataModel

list-remotes
Read-onlyIdempotent

Scan a Roblox game tree to inventory remote and bindable objects. Return each object's path and class to find remotes for signature inspection or traffic monitoring.

Instructions

Read-only inventory of every remote/bindable object in a part of the game tree. Resolves root (a Luau expression, default the whole game), walks its :GetDescendants() pcall-guarded, and collects every instance whose ClassName is RemoteEvent, RemoteFunction, UnreliableRemoteEvent, BindableEvent, or BindableFunction. For each it records its full path (GetFullName), class, and name. This is the map you build BEFORE spying: use it to discover which remotes exist and where, then feed an interesting path into get-remote-signature (to learn its shape) or monitor-remote (to watch one remote's traffic). Complements get-remote-spy-logs, which shows calls that have already happened; this shows the static set of remotes regardless of whether they have fired. Scanning the entire DataModel can be large, so results are capped at limit (a truncated flag is set when the cap is hit) and a per-class tally is always returned. Uses only :GetDescendants and reflection — no special executor functions required. Returns { ok, root, total, scanned, byClass, truncated, remotes } where remotes is a list of { path, class, name }, or { error }. Signature: { root: any?, limit: any?, threadContext: number? }. Phase: observe; cost=medium; idempotency=read-only. Requires: active-client. Produces: bounded-candidates. Safety: read-only. On failure: inspect tool-schema for exact fields, defaults, constraints, and an invocation example.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
rootNoLuau expression resolving to the Instance to scan under, e.g. 'game', 'game:GetService("ReplicatedStorage")', or 'game.Players.LocalPlayer.PlayerGui'. Its :GetDescendants() is walked. Evaluated as `return <root>`. Defaults to 'game' (the whole DataModel).game
limitNoMaximum number of remote/bindable entries to return (default 400). When the subtree contains more matching instances than this, the list is truncated to `limit` and `truncated` is set true (the byClass tally and `total` still reflect everything that was scanned up to the cap).
threadContextNoOptional Roblox thread identity for this call; omit it to use the server default.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.0.0-spies.2

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, but the description adds substantial context beyond them: pcall-guarded traversal, truncation at `limit` with a truncated flag, always-returned per-class tally, no executor functions required, requires active-client, and phase/cost metadata. This is rich behavioral disclosure, not restatement.

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?

Dense and somewhat long, but front-loaded with the core purpose and organized as purpose -> mechanics -> routing -> return shape -> signature/meta. Nearly every sentence adds usable information, though some metadata (phase/cost/idempotency) is redundant with annotations.

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?

Although no output schema exists, the description enumerates the return shape ({ ok, root, total, scanned, byClass, truncated, remotes } with per-entry fields) and error case, plus the truncation/failure guidance. For a complex, tree-scanning tool this is complete enough to call 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 coverage is 100% and the schema fully documents root, its default, limit's cap/truncation, and threadContext. The description largely restates these and adds the signature list; it doesn't add format or constraint meaning beyond what the schema already carries, so the 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 (read-only inventory of remotes/bindables) and precisely defines scope: walks a subtree's :GetDescendants() and collects instances of five named classes. It explicitly distinguishes itself from get-remote-spy-logs (static set vs already-fired calls) and names the downstream consumers, so an agent can place it 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 workflow: 'the map you build BEFORE spying', then feed a path into get-remote-signature or monitor-remote. It also states the exclusion case against get-remote-spy-logs, so when-to-use and when-to-use-something-else are both covered.

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