Skip to main content
Glama
okenjioxx

Roblox Executor MCP Server

by okenjioxx
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Grep across all scripts in the game

script-grep
Read-onlyIdempotent

Search decompiled Roblox scripts line by line for exact text or Luau patterns, returning matching lines with surrounding context grouped per script.

Instructions

Search decompiled Roblox scripts for a pattern, line by line, with surrounding context. Enumerates every client-readable LuaSourceContainer reachable from the active client (via QueryDescendants plus nil-parented scripts), decompiles each, and reports matching lines grouped per script. Matching uses Luau string.find: with literal=true the query is matched as a plain substring; otherwise it is treated as a Luau string pattern (note: Luau patterns, not JavaScript regex). Use exact identifiers or simple patterns; use semantic-search-scripts when behavior is known but names are not. Decompilation is best-effort and can be slow on large places, so the scan is capped by maxScripts. Signature: { query: string, root: any?, limit: any?, contextLines: any?, maxMatchesPerScript: any?, maxScripts: any?, literal: any?, caseSensitive: any?, threadContext: number? }. Phase: orchestrate; cost=medium; idempotency=read-only. Requires: active-client. Produces: structured-result. Safety: read-only. On failure: inspect tool-schema for exact fields, defaults, constraints, and an invocation example.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
rootNoRoot instance to enumerate scripts under (e.g. 'game', 'game.ReplicatedStorage'). Defaults to 'game'. Narrow this to keep the scan fast.game
limitNoMaximum number of scripts to return results from (default: 50).
queryYesThe search pattern. With literal=false it is interpreted as a Luau string pattern (%d, %w, %s, character classes [a-z], anchors, etc.). Use the literal flag for exact substring matching.
literalNoWhen true, treats the query as a plain literal substring - no pattern interpretation (string.find with plain=true). (default: false)
maxScriptsNoMaximum number of scripts to decompile and scan before stopping (default: 400).
contextLinesNoNumber of lines of context to show before and after each match (default: 2).
caseSensitiveNoWhen false, matches case-insensitively. (default: true)
threadContextNoOptional Roblox thread identity for this call; omit it to use the server default.
maxMatchesPerScriptNoMaximum number of matches to return per script (default: 20).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.0.0-spies.2

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare read-only/idempotent/non-destructive, yet the description adds substantial context beyond them: enumeration path (QueryDescendants plus nil-parented scripts), best-effort decompilation, the maxScripts cap, the active-client prerequisite, and the Luau-pattern (not JavaScript regex) matching semantics.

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

Conciseness3/5

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

The opening is well front-loaded and dense with useful behavior, but it then restates the full parameter signature (mostly typed as 'any') that the schema already provides, and repeats annotation-derived metadata lines like idempotency=read-only. Those blocks are padding against an otherwise efficient description.

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?

For a 9-parameter, no-output-schema tool, the description covers the return shape (matching lines grouped per script), performance caveats, prerequisites, and a failure path (inspect tool-schema), leaving nothing an agent needs to call it correctly.

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?

Schema coverage is already 100%, so baseline is 3, but the description adds genuine meaning by clarifying that literal=true means plain substring and otherwise the query is a Luau string pattern rather than a JS regex, which is the most likely source of misuse.

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+scope: grep decompiled Roblox scripts line by line with context, and describes what gets enumerated. It clearly separates itself from semantic-search-scripts by naming that sibling in the same breath.

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?

Explicitly says to use exact identifiers or simple patterns and to switch to semantic-search-scripts when behavior is known but names are not. It also warns that decompilation is slow on large places and advises narrowing root, giving concrete when-and-how guidance.

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