Skip to main content
Glama
okenjioxx

Roblox Executor MCP Server

by okenjioxx

Profile how long a function takes per call (MUTATES STATE via hookfunction)

trace-call-durations
Destructive

Profile a Luau function by hooking it to record call count, total, average, min, and max execution time, then fetch live stats or stop to restore the original.

Instructions

WRITES LIVE GAME STATE — INSTALLS A PERSISTENT GLOBAL HOOK. Per-function profiler: hook a target so that every invocation is timed with os.clock(), accumulating call count plus total/min/max time, then read the aggregated stats, then restore the original. This is the fastest way to answer 'how expensive is this function and how often does it run?' — ideal for finding the hot path in an anticheat loop, a render step, or a remote handler. Unlike count-function-calls (count only) it also measures duration; unlike hook-and-log-function it stores only aggregates (no per-call args), so it is cheap enough for hot paths. WORKFLOW (stateful — survives across tool calls via getgenv().__mcp_callTimings, keyed by functionPath): 1. action='start' with functionPath — resolves the target, captures the original, installs a timing wrapper that transparently calls the original and records elapsed time. Returns { started, key }. 2. action='fetch' with the same functionPath — returns { count, totalMs, avgMs, minMs, maxMs } so far WITHOUT stopping. Poll to watch live. 3. action='stop' with the same functionPath — restores the original and clears the entry. Returns final stats. CAVEATS: the hook is GLOBAL and PERSISTS until you stop it (or the client restarts), adds (small) timing overhead on every call, and a live function hook CAN TRIP ANTICHEAT — always stop when done. The original is called through real-time (its return values are passed back unchanged); timing/aggregation is pcall-isolated. Requires hookfunction, newcclosure, and getgenv; restoration uses hookfunction(target, original) with a restorefunction fallback. Returns { error } if a capability is missing, the target cannot be resolved, or there is no active profile for fetch/stop. Signature: { action: "start" | "fetch" | "stop", functionPath: string?, threadContext: number? }. Phase: act; cost=medium; idempotency=contextual-write. Requires: active-client, resolved-target, explicit-mutation-approval. Produces: bounded-event-snapshot, operation-receipt. Verify with: assert-state. Safety: MUTATING; writes live game/client state. On failure: inspect tool-schema for exact fields, defaults, constraints, and an invocation example.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
actionYes'start' installs the timing wrapper on functionPath; 'fetch' returns the aggregated timing stats so far (hook stays live); 'stop' restores the original function and clears the stats. Use the SAME functionPath for all three so they address the same registry entry.
functionPathNoLuau expression resolving to the function to profile, e.g. 'getsenv(game.Players.LocalPlayer.PlayerScripts.Main).update' or 'getrawmetatable(game).__namecall'. Evaluated as `return <functionPath>` and must resolve to a function. REQUIRED for 'start'. For 'fetch'/'stop' it is the registry key identifying which running profile to act on, so it must match the string used at start.
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?

Goes well beyond the destructiveHint/readOnlyHint/non-idempotent annotations: discloses the hook is GLOBAL and persists until stopped, adds timing overhead on every call, can trip anticheat, requires hookfunction/newcclosure/getgenv, uses pcall-isolation, and specifies fallback restoration. This is exactly the mutation-risk context an agent needs.

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?

Long but well-organized, front-loading the critical WRITES LIVE GAME STATE warning and structuring the WORKFLOW and CAVEATS clearly. The trailing Phase/cost/idempotency/Requires/Produces metadata block somewhat duplicates the annotations and could be trimmed.

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 stateful, mutating tool with no output schema, the description is complete: it explains the return shape at each step ({started,key}, {count,totalMs,avgMs,minMs,maxMs}, {error}) and the failure conditions. Nothing essential for correct invocation is missing.

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 description coverage is 100%, so the schema already documents each parameter thoroughly; baseline is 3. The description adds the combined signature and reinforces that functionPath must match across calls, but largely restates what the schema provides.

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 and resource: a per-function profiler that hooks a target and times every invocation with os.clock(), accumulating count plus total/min/max. It explicitly distinguishes itself from siblings, noting it measures duration unlike count-function-calls and stores only aggregates unlike hook-and-log-function.

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?

Names concrete use cases (finding the hot path in an anticheat loop, render step, or remote handler) and provides an explicit stateful workflow with the three actions and the condition for each. It also routes against alternatives by stating their tradeoffs.

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