Allows interaction with Roblox game clients, enabling code execution, script inspection, remote spy, GUI interaction, and more.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Roblox Executor MCP Execute Lua code to print 'Hello World' in the Roblox game."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server that allows Agents to interact with a running Roblox game client — execute code, inspect scripts, spy on remotes, and more.
Roblox Executor MCP includes a local web dashboard at:
http://localhost:16384/Use it to see connected Roblox clients, inspect scripts, run tools, view server logs, configure semantic search, and index games for semantic script search.
Related MCP server: Roblox MCP Server
Code Execution — Run Lua code and fetch data from the game client.
Script Inspection — Decompile scripts and search across all sources.
Instance Search — CSS-like selectors and hierarchy trees.
Remote Spy — Intercept, log, block, and ignore Remotes/Bindables via Cobalt.
GUI Interaction — Click buttons and type into text boxes.
Screenshot — Capture Roblox window screenshots (Windows only).
Multi-Client — Connect multiple Roblox clients at once.
Primary / Secondary — Multiple MCP instances auto-coordinate with automatic promotion. Supports remote relaying via --baseurl. See Advanced.
Node.js ≥ 18
A Roblox executor that supports loadstring, request, and (preferably) WebSocket
git clone https://github.com/notpoiu/roblox-executor-mcp.git
cd roblox-executor-mcpThe installer builds the server, lets you choose AI clients, writes supported MCP configs, and prints the Roblox loader script.
npm run install:harnessesIf your terminal has trouble with the interactive picker, use the plain numbered prompt:
npm run install:harnesses -- --plainIt can also help with:
cross-machine setup on the same LAN
copying the Roblox loader to your clipboard
optional Ollama embeddinggemma setup for semantic indexing
pulling latest repo changes before install/build
To update an existing install later, run:
npm run updateThe update command can stop currently running MCP server processes, optionally pull latest changes, and always rebuilds the server.
If you prefer to configure a client yourself, use the setup guide for your client:
Client | Guide |
Cursor | |
Claude Desktop | |
Claude Code | |
Codex CLI | |
Windsurf | |
Antigravity |
The installer prints this for you. Put it in your executor or Auto Execute:
local bridgeUrl = getgenv().BridgeURL or "localhost:16384"
loadstring(game:HttpGet("http://" .. bridgeUrl .. "/script.luau"))()Optional settings (set before the loadstring):
getgenv().BridgeURL = "10.0.0.4:16384" -- default: localhost:16384
getgenv().DisableWebSocket = true -- force HTTP polling
getgenv().DisableInitialScriptDecompMapping = true -- skip initial decompilationAfter the MCP server starts and Roblox connects, open the dashboard:
http://localhost:16384/Have a suggestion or need help? Join the Discord server.
This server allows arbitrary code execution. Only use with AI clients you trust. Port
16384has no authentication — never expose it to the internet. For cross-machine setups, use a local network, VPN, or SSH tunnel. See Advanced for details.
Block or unblock a Roblox remote by exact name and direction. Requires ensure-remote-spy first; use get-remote-spy-logs to discover candidates.
| Name | Required | Description | Default |
|---|---|---|---|
| remoteName | Yes | The exact name of the remote to block/unblock | |
| direction | Yes | Whether the remote is Incoming or Outgoing | |
| shouldBlock | No | true to block, false to unblock |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the mutation action (block/unblock) and the prerequisite, but does not describe any side effects, persistence, or scope of the blocking. The behavior is simple but could be more transparent about whether changes are permanent or session-scoped.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the purpose, and every word serves a purpose. No wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple toggle tool with full schema coverage and no output schema, the description adequately covers prerequisites and a discovery alternative. It nearly covers all needed context, though a note on scope or persistence would make it complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 all three parameters. The description adds minimal extra meaning beyond the schema, simply restating that the action uses 'exact name and direction'. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action (block or unblock), the resource (Roblox remote), and the constraints (by exact name and direction). It also mentions a prerequisite and an alternative tool for discovery, distinguishing it from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies a prerequisite ('Requires ensure-remote-spy first') and suggests using 'get-remote-spy-logs' to discover candidates. This provides clear context for when to use the tool. However, it does not explicitly state when not to use it or mention alternatives beyond the discovery step.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Clear all captured Cobalt remote spy logs. Requires ensure-remote-spy first.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosing behavioral traits. It only states the action and prerequisite, but does not clarify that the logs are permanently deleted, whether it affects the active client only, or if any confirmation is needed. This is insufficient for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the main purpose. Every word earns its place, with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema), the description covers the basic what and prerequisite. However, it misses important context: whether the action applies to all clients or just the active one (siblings suggest client context matters), and whether the operation is reversible. This gap reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the input schema is trivially complete. The description does not need to add parameter information. Baseline is 4 for zero parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Clear all captured Cobalt remote spy logs', using a specific verb (clear) and resource (remote spy logs). It naturally distinguishes from siblings like 'get-remote-spy-logs' (read vs write) and 'ensure-remote-spy' (setup vs teardown).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states a prerequisite ('Requires ensure-remote-spy first'), providing clear context for when to use. However, it does not mention when not to use or offer alternatives, though the verb choice makes the usage fairly obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Click a Roblox TextButton or ImageButton by firing its GUI signals. Use when direct UI activation is needed inside the active client.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | The instance path to the Button | |
| action | No | The specific signal to fire (e.g., 'Activated', 'MouseButton1Click'). If omitted, fires all standard click signals. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only mentions 'firing its GUI signals' without disclosing error handling, prerequisites, or side effects, leaving significant gaps for an interactive tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words, and all essential information is front-loaded efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple button-click tool, the description covers the core functionality but omits return values, error states, and prerequisites beyond client activity, leaving some context incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds value by noting that omitting the action parameter fires all standard click signals, clarifying default behavior beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it clicks a Roblox TextButton or ImageButton by firing GUI signals, making the action precise and distinguishing it from unrelated sibling tools like block-remote or script-grep.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It specifies when to use ('when direct UI activation is needed inside the active client'), providing clear context, though it lacks explicit exclusions or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Load or verify the Cobalt remote spy in the active Roblox client. Call before reading, clearing, blocking, or ignoring remote spy logs.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes actions as 'load or verify', implying idempotent and non-destructive. No annotations to contradict. However, doesn't detail what 'verify' entails.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with action. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple, parameterless tool. Specifies usage context. Minor omission: does not clarify idempotency or what happens if spy is already loaded.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters; schema coverage 100%. Description adds no param info as none exist. Baseline 4 per instructions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Explicitly states it loads or verifies the Cobalt remote spy. Distinguishes from siblings by indicating it's a prerequisite for reading, clearing, blocking, or ignoring remote spy logs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clearly specifies when to use: before reading, clearing, blocking, or ignoring remote spy logs. Provides actionable context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute Luau in the active Roblox client without returning output. Use get-data-by-code instead when you need returned values.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | The code to execute in the Roblox Game Client. This tool does NOT return output - use get-data-by-code if you need to retrieve data. | |
| threadContext | No | The thread identity to execute the code in (default: 8, normal game scripts run on 2) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry behavioral burden. It discloses the important no-return behavior but lacks details on safety, side effects, or error handling. The thread context default is already in schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero waste. First sentence states purpose and key constraint, second sentence directs to alternative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for selection and invocation: describes function, no-return behavior, and when to use sibling. Lacks error and safety context, but given schema coverage and sibling list, it is fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (baseline 3). Description adds value by reinforcing the no-return constraint for the 'code' parameter, but does not add new info for 'threadContext' beyond schema defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'execute', the resource 'Luau in the active Roblox client', and the key constraint 'without returning output'. It distinguishes from sibling 'get-data-by-code'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use alternative ('use get-data-by-code instead when you need returned values') and implies when to use this tool (when no return value is needed).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute a local .luau or .lua file in the active Roblox client without returning output. Use get-data-by-code instead when you need returned values.
| Name | Required | Description | Default |
|---|---|---|---|
| filePath | Yes | The absolute path to the .luau or .lua file to execute | |
| threadContext | No | The thread identity to execute the code in (default: 8, normal game scripts run on 2) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description is the sole source of behavioral info. It correctly states that no output is returned, but lacks details on potential side effects, error behavior, or prerequisites (e.g., active client).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using only two sentences to convey the core purpose and an important usage note. No redundant or unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential purpose and a key exclusion, but for a code execution tool, more context would be beneficial (e.g., error handling, file accessibility, requirement of an active client). However, given the simplicity of the tool and the presence of sibling tools, it is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters are fully described in the input schema (100% coverage), so the description adds no additional meaning. The baseline score of 3 applies as the schema already provides the necessary semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Execute', the resource 'local .luau or .lua file', and the context 'active Roblox client'. It also explicitly distinguishes from the sibling tool 'get-data-by-code' by noting the lack of returned output.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool (when returned values are not needed) and directs the agent to the alternative 'get-data-by-code' when values are required, offering clear usage boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read recent Roblox developer console logs from the active client. Use limit and logsOrder to control volume and ordering.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results to return (default: 50, to avoid overwhelming output) | |
| logsOrder | No | The order of the logs to return (default: NewestFirst) | NewestFirst |
| filter | No | Optional string filter; only logs containing this text are returned |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It indicates a read-only operation but lacks details such as whether logs are cleared after reading, rate limits, or authentication needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two succinct sentences that front-load the purpose and directly mention key parameters. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should hint at the return format (e.g., array of strings). It does not, leaving the agent unclear on what to expect. The description is adequate for a simple read operation but incomplete regarding output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions cover all three parameters (100% coverage), so the description adds limited value beyond reinforcing limit and logsOrder. It fails to mention the filter parameter, reducing its contribution.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads recent Roblox developer console logs from the active client, using specific verbs and resource. It distinguishes itself from sibling tools like 'get-remote-spy-logs' which target a different type of log.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides guidance on using limit and logsOrder to control output, but does not explicitly address when to use this tool versus alternatives or mention any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute Luau in the active Roblox client and return serialized raw Lua values. The code must return values; do not manually JSON-encode them.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | The code to execute in the Roblox Game Client (MUST return one or more values). Return raw Lua values - do NOT manually serialize tables or use JSONEncode, the connector handles serialization automatically. | |
| threadContext | No | The thread identity to execute the code in (default: 8, normal game scripts run on 2) | |
| timeout | No | Timeout in milliseconds for the response (default: 15000, max: 120000). Increase for long-running operations like decompiling many modules. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden for behavioral traits. It does not mention safety, side effects, error handling, or the potential for client crashes or state mutation. The description lacks warnings about executing arbitrary code.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with the first sentence front-loading the primary purpose. No wasted words; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a straightforward execution tool but missing details on return format (serialized raw Lua values) and error behavior. No output schema further increases need for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds marginal value by stating the execution context and serialization rule, but the schema already documents parameters thoroughly. No additional meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (execute Luau), resource (active Roblox client), and outcome (return serialized values). It distinguishes from siblings like 'execute' and 'execute-file' by specifying Luau execution and serialized return.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like 'execute'. The only constraint is 'code must return values; do not manually JSON-encode', but no context on appropriate use cases or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a depth-limited hierarchy of descendants under a Roblox instance. Use for broad structure exploration; use search-instances for selector-based filtering.
| Name | Required | Description | Default |
|---|---|---|---|
| root | Yes | The instance path to get the tree from (e.g., 'game.Workspace', 'game.Workspace.CurrentRooms') | |
| maxDepth | No | Maximum depth to traverse (default: 3). Higher values return more detail but larger output. | |
| classFilter | No | Optional class name filter — only show instances that IsA this class (e.g., 'BasePart', 'Model'). Leave empty to show all. | |
| maxChildren | No | Maximum number of children to show per node (default: 50). Prevents overwhelming output for large containers. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It mentions depth-limiting but does not explicitly state that the tool is read-only or non-destructive. For a retrieval tool, this is adequate but could be more transparent about side effects. Schema coverage is high, but behavioral traits beyond the basic operation are not disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with purpose and sibling differentiation. No unnecessary words or repetition. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (4 parameters, high schema coverage, no output schema), the description is mostly complete. It covers purpose and usage guidelines. It could mention the return format (tree structure) but is not critical. The sibling distinction adds context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 all parameters well. The description does not add significant parameter-specific information beyond the general purpose. It mentions 'depth-limited' which relates to maxDepth, but otherwise relies on the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it retrieves a depth-limited hierarchy of descendants, with specific verb ('Get') and resource ('descendants tree'). It distinguishes itself from sibling tool 'search-instances' by noting the use case for broad structure exploration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use this tool ('for broad structure exploration') and when to use the alternative ('use search-instances for selector-based filtering'). This provides clear guidance on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get current Roblox place and universe metadata such as PlaceId, GameId, and PlaceVersion.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavioral traits. 'Get' clearly indicates a read-only operation with no side effects. While it doesn't explicitly state lack of modification, the verb is sufficient for a simple retrieval tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no superfluous words. It is front-loaded with the action and resource, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter retrieval tool with no output schema, the description provides sufficient context by listing example metadata. It is complete enough for an agent to understand the tool's purpose, though additional detail on the return format could enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters and 100% schema coverage, so the description does not need to add parameter semantics. Baseline for 0 params is 4, and the description appropriately omits parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'current Roblox place and universe metadata', listing specific examples like PlaceId, GameId, and PlaceVersion. This distinguishes it from sibling tools that perform actions or modifications.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing place/universe metadata but lacks explicit guidance on when to use this tool versus alternatives or when not to use it. No when-not or alternative tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List captured Cobalt remote and bindable call logs. Requires ensure-remote-spy first; supports direction and name filters to narrow noisy logs.
| Name | Required | Description | Default |
|---|---|---|---|
| direction | No | Filter by call direction (default: Both) | Both |
| remoteNameFilter | No | Optional filter — only return logs for remotes whose name contains this string (case-insensitive) | |
| limit | No | Maximum number of remote logs to return (default: 50) | |
| maxCallsPerRemote | No | Maximum number of recent calls to return per remote (default: 5) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description bears full burden. It discloses read-only behavior (listing logs) and a critical dependency (ensure-remote-spy). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences. First defines purpose, second adds prerequisite and filter capability. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for a simple read tool with full schema coverage. Covers prerequisite and filter usage. No output schema but output is implied. Minor lack of explanation of 'remote and bindable call logs' but acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with all parameters described. Description mentions direction and name filters but adds no new meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool lists captured remote and bindable call logs. Verb 'List' is specific and the resource type is defined. Distinguishes from sibling tools like 'clear-remote-spy-logs' which perform different actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states prerequisite 'Requires ensure-remote-spy first' and mentions filter support. No explicit when-to-use vs alternatives, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get decompiled source for a Roblox script by path, script proxy, or getter code. Use startLine/endLine for a focused range when the full script is large.
| Name | Required | Description | Default |
|---|---|---|---|
| scriptGetterSource | No | The code that fetches the script object from the game (should return a script object, and MUST be client-side only, will not work on Scripts with RunContext set to Server) | |
| scriptPath | No | The path to the script to get the content of. If passing a GC'd script proxy (e.g. <ScriptProxy: 1_316566>), use the literal angle brackets < > — do NOT HTML-encode them as < or >. | |
| startLine | No | Optional start line number (1-based) to return only a range of lines from the decompiled script. If omitted, returns the full script. | |
| endLine | No | Optional end line number (1-based, inclusive) to return only a range of lines. Defaults to end of script if startLine is set but endLine is omitted. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It does not mention side effects, error handling, permissions, or performance characteristics. The read-only nature of fetching decompiled source is implied but not stated, and there is no mention of what happens on failure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the main purpose, and contains no filler. Every sentence adds value, making it efficient for an AI agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations. The description does not explain the return format (decompiled source structure) or clarify that at least one of scriptGetterSource or scriptPath is needed despite no required parameters. This leaves important gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, providing baseline at 3. The description adds value by explaining how to use scriptPath with literal angle brackets for script proxies and that scriptGetterSource must be client-side. This extra context goes beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get decompiled source for a Roblox script by path, script proxy, or getter code.' It uses a specific verb ('Get') and resource ('decompiled source'), and distinguishes three input methods. This clearly separates it from sibling tools like 'execute' or 'script-grep'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides guidance for using startLine/endLine for large scripts, but does not explicitly compare this tool to alternatives or state when not to use it. Given the sibling list, this is the only tool for retrieving script content, so usage context is implied but not fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ignore or unignore logging for a Roblox remote by exact name and direction. Requires ensure-remote-spy first; ignored remotes still fire.
| Name | Required | Description | Default |
|---|---|---|---|
| remoteName | Yes | The exact name of the remote to ignore/unignore | |
| direction | Yes | Whether the remote is Incoming or Outgoing | |
| shouldIgnore | No | true to ignore, false to unignore |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description explains that ignored remotes still fire, but lacks details on persistence, permissions, or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences, front-loaded with purpose, no superfluous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema; description covers prerequisite and a behavioral note. Could mention what happens when toggling a non-existent remote but is largely complete for a simple toggle tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description reiterates 'by exact name and direction' but adds no new meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool ignores or unignores logging for a Roblox remote by exact name and direction, distinguishing it from sibling tools like block-remote.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It specifies the prerequisite 'Requires ensure-remote-spy first' and notes 'ignored remotes still fire,' but does not explicitly compare with alternatives like block-remote.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List connected Roblox game clients with clientId and session metadata. Use before set-active-client when multiple clients are connected or the target client is unknown.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It indicates a read-only listing operation with metadata, but does not disclose any potential side effects, performance impact, or permissions required. For a simple list tool, this is adequate but not detailed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first states purpose with details about what is listed, second gives usage guidance. No redundant information, front-loaded, and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the return (clientId and session metadata) despite no output schema. For a zero-parameter list tool with low complexity, this is complete and sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, and schema coverage is 100%. The description does not need to provide parameter details. Baseline for zero parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists connected Roblox game clients with clientId and session metadata. It distinguishes itself from the sibling tool 'set-active-client' by recommending its use before that tool when multiple clients are connected or the target is unknown.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to use this tool before 'set-active-client' when multiple clients are connected or the target client is unknown. This provides clear context but does not specify when not to use it or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List visible Roblox OS windows with PIDs. Use before screenshot-window when multiple Roblox windows may be open.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; the description does not disclose behavioral traits such as side effects, permissions, or safety. It only states the action without elaborating on invariants or potential impacts.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences front-loading the action and purpose, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list tool with no output schema, the description sufficiently explains what it does and when to use it. Could be improved by explicitly noting it does not accept filters, but overall complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so the description adds meaning by clarifying the output includes PIDs. With 100% schema coverage and zero params, baseline is 4; description covers the intent well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the verb 'list' and the resource 'visible Roblox OS windows with PIDs', and it distinguishes itself from the sibling tool 'screenshot-window' by suggesting usage context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Directly advises 'Use before screenshot-window when multiple Roblox windows may be open', providing clear when-to-use guidance and directing to an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Capture an actual OS screenshot of a Roblox window via Windows APIs. Provide pid when multiple windows are open; secondary servers relay capture to the primary host.
| Name | Required | Description | Default |
|---|---|---|---|
| pid | No | The PID (process ID) of the Roblox window to capture. If omitted and only one Roblox window exists, it is captured automatically. If multiple windows exist and no pid is provided, the tool returns a list of windows for disambiguation. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses OS-level capture via Windows APIs and server relay. However, does not mention side effects like resource usage, permissions, or output format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. Purpose is front-loaded, parameter guidance follows efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description covers the primary behavior and parameter use case. Missing return format details but acceptable given the tool's straightforward nature.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter (pid) with 100% schema coverage. Description reinforces the need for pid when multiple windows exist but adds no new semantic meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'capture an actual OS screenshot' and the resource 'Roblox window', with method 'via Windows APIs'. It distinguishes from sibling tools like list-roblox-windows.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides guidance on when to provide the pid parameter ('when multiple windows are open') and mentions relay to primary host. Lacks explicit when-not-to-use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search decompiled Roblox scripts with JavaScript regex or literal string matching. Use for exact identifiers or code patterns; use semantic-search-scripts when behavior is known but names are not.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | The search pattern. Supports JavaScript RegExp syntax: \d, \w, \s, \b, character classes [a-z], alternation (foo|bar), quantifiers (+, *, ?), groups, lookaheads, etc. Use the literal flag for exact string matching. | |
| limit | No | Maximum number of scripts to return results from (default: 50) | |
| contextLines | No | Number of lines of context to show before and after each match (default: 2) | |
| maxMatchesPerScript | No | Maximum number of matches to return per script (default: 20) | |
| maxResults | No | Maximum total number of matches across ALL scripts (default: unlimited). Use this to cap total matches, e.g. maxResults=1 to find just the first match. | |
| literal | No | When true, treats the query as a plain literal string - no regex interpretation. Equivalent to grep -F / ripgrep -F. (default: false) | |
| caseSensitive | No | When false, matches case-insensitively. Equivalent to grep -i. (default: true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing behavioral characteristics. It implies a read-only search operation but does not explicitly state that it does not modify scripts or require special permissions. More detail on side effects or constraints would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences that front-load the core purpose and usage comparison. Every word adds value with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there are 7 well-documented parameters and no output schema, the description provides adequate context for a grep-like tool. It could be improved by mentioning the return format or limitations (e.g., only searches decompiled scripts), but it is still sufficiently complete for effective tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the baseline is 3. The tool description does not add additional meaning beyond what the schema already provides for parameters. It focuses on usage context rather than parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: searching decompiled Roblox scripts with JavaScript regex or literal string matching. It also distinguishes from the sibling tool 'semantic-search-scripts' by specifying use cases (exact identifiers or code patterns vs. behavior known but names not).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use this tool (exact identifiers or code patterns) and when to use the alternative 'semantic-search-scripts' (behavior known but names not). This provides clear decision guidance for the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Roblox instances with QueryDescendants selector syntax. Use for class, name, tag, property, and attribute queries against a chosen root.
| Name | Required | Description | Default |
|---|---|---|---|
| selector | Yes | Selector string to filter instances. Supports classes (Part), tags (.Tagged), names (#HumanoidRootPart), properties ([CanCollide = false]), attributes ([$QuestId] or [$Health = 100]), child/descendant combinators (> and >>), OR selectors (,), :not(), and :has(); chain selectors for AND logic, e.g. Part.Tagged[Anchored = false]. | |
| root | No | The root instance to search from (e.g., 'game.Workspace', 'game.ReplicatedStorage'). Defaults to 'game' if not specified. | game |
| limit | No | Maximum number of results to return (default: 50, to avoid overwhelming output) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It implies a read-only search operation but does not explicitly state safety, side effects, or result handling. Adequate but could be more explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, each earning its place. First sentence states the action, second expands on usage. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the search capability and syntax but omits details about return value format, sorting, or behavior when no results are found. With no output schema, more context would be helpful. Adequate but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed parameter descriptions. The description adds a summary of query capabilities but does not significantly enhance understanding beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Search Roblox instances with QueryDescendants selector syntax' and lists specific use cases (class, name, tag, property, attribute queries), distinguishing it from sibling tools like get-descendants-tree or semantic-search-scripts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for querying by attributes but does not explicitly state when to use this tool versus alternatives or provide exclusions. No guidance on when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find decompiled Roblox scripts by behavior using semantic embeddings. Use when exact identifiers are unknown; use script-grep for exact text or regex.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Natural-language description of the code behavior to find. | |
| limit | No | Maximum number of semantic matches to return (default: 10, max: 50). | |
| minScore | No | Optional minimum cosine similarity score. Typical useful values are 0.2-0.5. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavior. It mentions semantic embeddings and cosine similarity in parameter descriptions but does not detail return behavior, max result handling, or potential side effects. Adequate but could be more explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences that front-load purpose and then provide usage guidance. No extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Completeness is adequate for a search tool with clear usage context, but lacks description of return value format or error behavior. With no output schema, more detail on what is returned would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds no additional parameter context beyond what's in the schema, but the schema descriptions (e.g., cosine similarity range) are already informative.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds decompiled Roblox scripts by behavior using semantic embeddings, with a specific verb and resource, and distinguishes from sibling tool 'script-grep'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use ('when exact identifiers are unknown') and when to use an alternative ('use script-grep for exact text or regex'), providing clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Route future Roblox tool calls to the specified connected client. Use list-clients first if you need available clientIds.
| Name | Required | Description | Default |
|---|---|---|---|
| clientId | Yes | The client ID to set as active. Use list-clients to get available client IDs. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It states the behavioral effect of routing future calls, but lacks details on error handling or consequences of invalid clientId.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, no unnecessary words. Efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for a simple configuration tool with one required parameter. Explains what it does, prerequisite (list-clients), and effect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description covers 100% of parameters, so baseline is 3. Description adds overall purpose but no additional parameter-specific details beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Title and description clearly state the tool sets the active client for routing future calls. It distinguishes from sibling tools like list-clients by its specific purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description explicitly advises using list-clients first to get clientId, providing clear usage context. No exclusions mentioned, but adequate for a simple tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Enter text into a Roblox TextBox by path. Can simulate keystrokes or set Text directly based on useKeyPress.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | The instance path to the TextBox | |
| text | Yes | The string to type into the TextBox | |
| enter | No | Whether to press Enter after typing | |
| useKeyPress | No | If true, simulates real keystrokes using VirtualInputManager / keypress. If false, directly sets the Text property. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses two behaviors (simulated keystrokes or direct text setting) and the option to press Enter. However, it omits side effects, error conditions (e.g., invalid path), prerequisites (e.g., focus), and whether the operation is synchronous. With no annotations, this lack of detail limits transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences covering the main functionality. It could be structured more clearly (e.g., bullet points), but it is efficient and front-loaded with the key action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of UI interaction and lack of output schema or annotations, the description is incomplete. It does not address error handling, waiting for completion, or validation of inputs like path existence. More context is needed for reliable tool use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes all four parameters with good detail (100% coverage). The description adds some context by explaining the useKeyPress distinction beyond the schema definition. This is helpful but not substantial, so a baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool enters text into a Roblox TextBox, with two modes (keystrokes or direct set). It specifies the resource and action, making the purpose clear. However, it does not explicitly differentiate from sibling tools like click-button, which could also interact with UI elements.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. For instance, no mention of when to prefer this over click-button or execute. The description mentions two modes (useKeyPress true/false) but does not advise on choosing between them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0block-remoteclear-remote-spy-logsclick-buttonensure-remote-spyexecuteexecute-fileget-console-outputget-data-by-codeget-descendants-treeget-game-infoget-remote-spy-logsget-script-contentignore-remotelist-clientslist-roblox-windowsscreenshot-windowscript-grepsearch-instancessemantic-search-scriptsset-active-clienttype-text-boxEach tool has a clearly distinct purpose, from execution (execute, execute-file, get-data-by-code) to remote spy management (ensure-remote-spy, block-remote, ignore-remote) to UI interaction (click-button, type-text-box) and exploration (get-descendants-tree, search-instances, script-grep, semantic-search-scripts). No two tools overlap in functionality.
All tools follow a consistent verb_noun pattern in snake_case, such as block-remote, clear-remote-spy-logs, get-game-info, set-active-client. The naming is predictable and easy to understand.
With 21 tools, the server covers a broad but well-scoped set of operations for Roblox client automation, including execution, remote spy, UI interaction, and exploration. The count feels appropriate and not overwhelming.
The tool surface provides comprehensive coverage for the server's purpose: execution (with and without return), remote spy lifecycle (ensure, read, clear, block, ignore), UI manipulation, script analysis, and instance exploration. There are no obvious gaps that would hinder common workflows.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Develop, manage, and debug Railway projects, services, and deployments from within agents.
Operate Linux, macOS and Windows from your LLM. Every action runs through an auditable allowlist.
Connect agents to 6DuckLearn memory, approvals, and runtime control.
Build, validate, and deploy multi-agent AI solutions from any AI environment.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/xixfaces/roblox-executor-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
