mcp roblox
Scored across 17 tools
Most tools have clear distinct purposes, but execute and get-data-by-code both run Luau and differ mainly in returning output, which could cause misselection. The exploration and search tools are also similar but their descriptions clearly separate structural, lexical, and semantic search.
Tool names generally follow a lowercase hyphenated verb-object pattern like get-game-info or list-clients, making them predictable. Minor deviations like remote-spy and script-grep are slightly less conventional but still readable and within the same style.
Seventeen tools is slightly above the ideal range but each tool earns a place in the Roblox client manipulation and inspection domain. The count feels reasonably scoped rather than bloated.
The set covers core workflows well: UI interaction, script execution, instance exploration, script analysis, client management, and remote event inspection. Minor gaps exist such as no explicit keyboard-key-only input or arbitrary coordinate clicking, but agents can work around these.
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?
Discloses the mechanism (firing signals) but does not cover side effects, prerequisites, or return behavior. Without annotations, the description carries the full burden.
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, efficient and well-structured. Could be slightly more concise but no waste.
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 action tool, but lacking return value details and any output schema.
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?
Adds value beyond schema by explaining default behavior for omitted 'action' parameter (fires all standard click signals). Schema coverage is 100%.
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 action ('Click a Roblox TextButton or ImageButton') and the method ('firing its GUI signals'), making the tool's purpose distinct from sibling tools.
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 a clear use case ('direct UI activation inside the active client'), but lacks explicit when-not or alternatives.
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. To verify the effect, follow up with a small get-console-output (low limit) or a targeted get-data-by-code probe.
| 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly discloses that no output is returned and that effects must be verified through separate tools, which is non-obvious and useful. It does not mention side-effect risk or error handling, but the execution context is explicit enough that this is a minor gap.
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?
Three dense sentences deliver the purpose, the no-return behavior, the alternative tool, and a verification strategy with no filler or repetition. The most important constraint, lack of return output, is front-loaded.
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 definition gives an agent enough to invoke the tool correctly: what code runs, where it runs, what is not returned, and how to confirm the effect. It could more explicitly warn about irreversible game-state mutation or require an active client to be set, but the sibling set and the word 'active' provide sufficient 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%, and the parameter descriptions already provide meaningful detail: code is described as non-returningasi and threadContext has a default and a real-world example. The prose description does not add new parameter-level semantics beyond the schema, so the baseline score of 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 states a specific action, 'Execute Luau', identifies the target, 'the active Roblox client', and adds a key qualifier, 'without returning output', that clearly differs from get-data-by-code. This makes the tool's purpose and scope immediately distinguishable 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 explicitly tells the agent to use get-data-by-code instead when returned values are needed, which is clear alternative routing. It also prescribes a follow-up verification pattern using get-console-output or a targeted get-data-by-code probe, giving practical when-to-use guidance.
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. To verify the effect, follow up with a small get-console-output (low limit) or a targeted get-data-by-code probe.
| 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, the description carries the full burden. It discloses that no output is returned and that execution happens in the active Roblox client, which is a key behavioral trait. It doesn't cover failure modes or potential side effects on the game state, but the no-return and active-client constraints are clearly stated.
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?
Three sentences, each with a distinct purpose: the core action, the alternative, and the verification step. Front-loaded with the most important information (what it does, no output) and ends with actionable follow-up. Zero waste.
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 tool with two parameters and no output schema, the description covers the essential aspects: what it does, when not to use it, and how to verify the outcome. It does not explicitly mention the threadContext parameter's meaning, but that is already in the schema. The absence of error-handling details is minor given the tool's simplicity.
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% and both parameters (filePath, threadContext) are already described in the schema. The description adds no additional parameter-specific meaning beyond what the schema provides, so a baseline of 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?
States a specific verb (execute) and resource (a local .luau/.lua file) in the active Roblox client, and explicitly notes it returns no output. This clearly distinguishes it from get-data-by-code, which is for returned values, and from other siblings like execute which might be more generic.
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 explicit guidance: 'Use get-data-by-code instead when you need returned values.' Also recommends follow-up verification with get-console-output or get-data-by-code to confirm the effect, which is actionable and helpful for an agent.
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: 10, to avoid overwhelming output) | |
| filter | No | Optional string filter; only logs containing this text are returned | |
| logsOrder | No | The order of the logs to return (default: NewestFirst) | NewestFirst |
| summaryOnly | No | When true, return log counts by level instead of individual log lines. | |
| maxOutputChars | No | Maximum characters to return to the model (default: 6000, max: 32000). Raise only when a single result genuinely needs more; large outputs degrade model performance. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits itself. It explicitly states 'Read', indicating a non-destructive operation, and mentions 'recent' logs, implying a limited window. However, it does not disclose any potential side effects (e.g., whether it clears the console, requires specific client state, or how errors are handled). The read-only nature is clear, but more detail 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 exceptionally concise: two sentences, with the primary action front-loaded. The parameter guidance in the second sentence is directly actionable and adds no redundancy. Every word 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?
Given the tool has five parameters, no output schema, and no annotations, the description covers the core purpose and key controls. It does not describe the return format (e.g., array of log strings) or behavior of summaryOnly, but the schema documents those parameters. For a simple read tool, this is adequate and nothing critical is missing.
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 five parameters fully (100% coverage), so the description need not restate them. It does add value by highlighting 'limit and logsOrder' as the key controls for volume and ordering, which helps an agent prioritize these knobs. This is a modest but useful addition 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 'Read' and resource 'Roblox developer console logs', distinguishing it from sibling tools like get-script-content or get-descendants-tree. It also notes the source is 'the active client', which clarifies scope. No ambiguity remains about what the tool does.
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 reading recent console logs from the active client. It doesn't provide explicit alternatives or when-not-to-use clauses, but there is no direct sibling competing for this function. The context is clear enough for an agent to know when to invoke it.
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. Prefer the specialized tools (search-instances, get-descendants-tree, get-script-content, script-grep) for exploration; use this only for small, targeted value probes. The code must return values; do not manually JSON-encode them.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | Code to run in the Roblox client (MUST return one or more values). Return small, specific values — never whole instances or large tables. Return raw Lua values; the connector serializes them (do NOT JSONEncode yourself). | |
| timeout | No | Timeout in milliseconds for the response (default: 15000, max: 120000). Increase for long-running operations like decompiling many modules. | |
| threadContext | No | The thread identity to execute the code in (default: 8, normal game scripts run on 2) | |
| maxOutputChars | No | Maximum characters to return to the model (default: 6000, max: 32000). Raise only when a single result genuinely needs more; large outputs degrade model performance. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden for behavioral disclosure. It mentions that the code must return values and that the connector serializes them, but it does not disclose potential side effects of executing arbitrary code in the client, such as state modification or crash risk, nor does it state any permission requirements. This is a significant gap for a code-execution 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 two sentences, with the purpose stated first and usage guidance second. No filler or redundancy – every sentence contributes.
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 tool that executes arbitrary code, the description leaves out important context such as error behavior, side effects, and what happens if the code does not return values. While the schema covers parameter details, the description alone is not complete enough for an agent to safely invoke this tool without additional assumptions, especially with no annotations or output schema.
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 fully documents all four parameters. The description adds no new parameter-level meaning beyond reiterating the return-value requirement for the code parameter, which is also in 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 the tool executes Luau in the active Roblox client and returns serialized raw Lua values, which distinguishes it from exploration-only tools like search-instances. However, it does not differentiate itself from the similarly named 'execute' siblings, which may also run code in the client, leaving some ambiguity.
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 the agent to prefer specialized tools (search-instances, get-descendants-tree, get-script-content, script-grep) for exploration, and to use this tool only for small, targeted value probes. This gives clear when-to-use and when-not-to-use guidance for the exploration category, though it omits guidance about the 'execute' and 'execute-file' siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Explore the structure under a Roblox instance. Defaults to a compact summary (child/class counts); set summaryOnly=false for the full tree. 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: 2, max: 5). 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: 20, max: 30). Prevents overwhelming output for large containers. | |
| summaryOnly | No | When true (default), return compact child counts and class counts instead of the full tree. Set false only when you need the actual hierarchy. | |
| maxOutputChars | No | Maximum characters to return to the model (default: 6000, max: 32000). Raise only when a single result genuinely needs more; large outputs degrade model performance. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the default summary mode and the toggle for the full tree, which is meaningful, but it does not mention read-only behavior, potential performance cost, or how output size is constrained beyond what the schema already states.
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 only two sentences, with the main purpose front-loaded and the key usage toggle and sibling pointer following immediately. Every sentence earns its place with no 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?
For a read-only exploration tool with all six parameters documented and no output schema, the description plus schema gives an agent enough to select and invoke the tool correctly. A minor gap is that the exact structure of the returned summary is not elaborated, but the description provides sufficient expectations.
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% and every parameter has a clear description with defaults, ranges, and examples. The description adds little beyond restating the summaryOnly behavior, so the schema carries the load and the 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?
States a specific operation ('Explore the structure under a Roblox instance') and explicitly distinguishes it from search-instances by mentioning selector-based filtering. An agent knows exactly what this tool does and how it differs from its closest sibling.
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 clear context for when to use the tool: defaults to a compact summary, and tells the agent to set summaryOnly=false when the full tree is needed. It also points to search-instances as the alternative for selector-based filtering, giving actionable routing guidance.
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 |
|---|---|---|---|
| maxOutputChars | No | Maximum characters to return to the model (default: 6000, max: 32000). Raise only when a single result genuinely needs more; large outputs degrade model performance. | |
| includeDescription | No | When true, include the (potentially long) place description text. Off by default to keep output small. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a read-only operation via the verb 'Get' but does not specify what happens when no game is active, whether output is truncated, or any potential side effects. The tool's behavior beyond the listed fields is opaque.
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?
A single sentence that is immediately informative, with the core action and key outputs front-loaded. There is no wasted wording or redundant phrasing.
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 metadata getter, the description is adequate but not complete. It lists example fields but does not describe the full return structure or behavior under error conditions. With no output schema, agents may not know what additional metadata is available or how results are formatted, leaving some ambiguity.
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 both parameters (maxOutputChars, includeDescription) are already documented in the schema. The tool description adds no extra parameter guidance, so it neither helps nor hinders. 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 states a specific verb ('Get') with a clear resource ('current Roblox place and universe metadata') and lists concrete examples (PlaceId, GameId, PlaceVersion). It unambiguously distinguishes this from sibling tools like get-script-content or get-descendants-tree, which target scripts and instance trees, not game metadata.
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 no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., an active Roblox session) or contrast with other metadata-related tools. Agents are left to infer its applicability from the name and context.
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 |
|---|---|---|---|
| endLine | No | Optional end line number (1-based, inclusive). If omitted, returns up to maxLines lines. | |
| maxLines | No | Maximum lines to return (default: 80, max: 2000). Use explicit startLine/endLine ranges for large scripts. | |
| startLine | No | Optional start line number (1-based). If omitted, returns a bounded preview from line 1 instead of the full script. | |
| 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 >. | |
| maxOutputChars | No | Maximum characters to return to the model (default: 6000, max: 32000). Raise only when a single result genuinely needs more; large outputs degrade model performance. | |
| 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) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral disclosure burden. It communicates that output is decompiled source and that large scripts benefit from line-range requests, but it does not describe failure modes, partial-return behavior, or whether getter code has side effects beyond what the schema already states.
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 short, front-loaded, and free of filler. It efficiently conveys the core purpose and one important usage tactic, though it could have included sibling differentiation without becoming verbose.
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 six-parameter tool with no output schema and no annotations, the description is somewhat thin. It implies one of three lookup modes is needed but never states that at least one must be provided, and it does not explain return format or error behavior beyond what the schema says.
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 baseline is 3. The description adds a high-level mapping of the three lookup mechanisms, but most parameter meaning is already fully documented in the input 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 uses a specific verb and resource: 'Get decompiled source for a Roblox script'. It also names the three lookup modes (path, script proxy, getter code), making it clear what the tool does and how it differs from search-oriented siblings like 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 gives clear practical guidance: use startLine/endLine ranges when the script is large. It does not explicitly contrast this tool with alternatives such as script-grep or semantic-search-scripts, but the usage context is clear.
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?
No annotations are provided, so the description carries the full burden. It states the tool lists clients but does not disclose any potential behavioral traits such as side effects, safety, or prerequisites. For a simple list operation, it's adequate but not exemplary.
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, front-loaded with the purpose, and includes a usage guideline. Every sentence adds value; 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?
Given the tool's simplicity (no params, no output schema), the description covers the essential purpose and when to use it. It distinguishes from sibling tools. However, it could mention what 'session metadata' includes 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?
The input schema has zero parameters and 100% coverage. The description adds no parameter information, which is expected. Per the guidelines, 0 parameters gets a baseline score of 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 explicitly recommending its use before that tool.
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 a clear usage guideline: use this tool before set-active-client when multiple clients are connected or the target client is unknown. This tells the agent when to invoke it.
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?
Although no annotations are provided, the description discloses that only 'visible' windows are listed and that PIDs are included, which adds behavioral context beyond the name. However, it could be improved by noting that no parameters are required and that the operation is read-only and non-destructive.
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, front-loaded sentence that immediately states the tool's purpose, followed by a usage hint. Every word is necessary and contributes to clarity without 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?
Given the tool's simplicity and lack of output schema, the description provides sufficient context: what it does and when to use it. It could be more complete by mentioning that no arguments are needed, but the empty schema already conveys that.
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?
With zero parameters, the description does not need to add parameter information, and it correctly implies that the tool requires no input. The baseline for 0 parameters is 4, and the description does not conflict with the empty 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 lists visible Roblox OS windows with PIDs, specifying the verb 'list' and the resource 'Roblox OS windows', which distinguishes it from the sibling tool 'screenshot-window' that takes a screenshot of a specific window.
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 advises to 'Use before screenshot-window when multiple Roblox windows may be open', providing clear when-to-use guidance and naming an alternative sibling tool, which helps the agent decide which tool to invoke.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inspect and control Cobalt remote-spy state. Cobalt loads automatically. Use operation=list before changing a remote. block/unblock prevents or permits matching calls; ignore/unignore only changes whether matching calls are logged. Remote names are exact for state changes; list.nameFilter is a case-insensitive substring filter. Start with summaryOnly=true and small limits, then request arguments only for a narrowed remote.
| 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 full burden and does so thoroughly. It discloses automatic loading, the list-before-change requirement, exact vs case-insensitive matching, the semantic difference between blocking and ignoring, and performance-conscious usage.
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?
Five dense sentences, front-loaded with the core purpose, and every sentence adds operational value. There is no fluff or repetition, and the structure flows from overview to operations to performance guidance.
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 empty schema, absent annotations, and no output schema, the description is remarkably complete. It covers operation semantics, filtering behavior, state-change sequencing, and safe exploration practices, leaving the agent well-equipped to invoke the 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?
The input schema is empty, so the description must compensate. It does, explaining operation values, exact remote names, list.nameFilter as a case-insensitive substring filter, and summaryOnly/limit usage. This is exactly the semantic depth an agent needs.
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 states a specific verb+resource: 'Inspect and control Cobalt remote-spy state.' It further enumerates distinct operations (list, block/unblock, ignore/unignore), making it easy for an agent to distinguish from sibling tools like execute or list-clients.
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 gives explicit operational sequencing: 'Use operation=list before changing a remote' and recommends starting with summaryOnly=true and small limits. It lacks explicit comparison to sibling tools, so it stops short of full alternative-selection guidance.
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. Returns a downscaled JPEG to limit vision-token cost. 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. | |
| maxWidth | No | Maximum image width in pixels; the screenshot is downscaled to this (default: 1280). Lower values cost fewer vision tokens. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It states the capture mechanism (Windows APIs), the output format and rationale (downscaled JPEG to limit vision-token cost), and the relay behavior on secondary servers. This is meaningful context beyond the 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?
Three concise sentences front-load the core purpose and immediately state the return type and cost rationale. Every sentence earns its place, and there is no redundant 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?
The description covers the main inputs, output format, and expected behavior in multi-window and multi-server scenarios. A return value schema is absent, so mentioning the downscaled JPEG return is helpful, though the exact representation of the image data is not specified.
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 fully documents both pid and maxWidth. The description repeats the 'provide pid when multiple windows are open' guidance and indirectly references maxWidth through the downscaling rationale, but does not add substantive new parameter semantics 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 opens with a specific action and resource: capturing an actual OS screenshot of a Roblox window via Windows APIs. It clearly distinguishes this from in-game data or script-related tools by emphasizing the OS-level screenshot and JPEG 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?
The description gives a concrete usage condition: provide pid when multiple windows are open. It also notes the relay behavior on secondary servers. While it does not explicitly name alternatives, no sibling tool performs OS screenshots, so the condition-based guidance is sufficient.
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 |
|---|---|---|---|
| limit | No | Maximum number of scripts to return results from (default: 10) | |
| query | Yes | Search pattern (JavaScript RegExp syntax). Set literal=true for an exact string match. | |
| literal | No | When true, treats the query as a plain literal string - no regex interpretation. Equivalent to grep -F / ripgrep -F. (default: false) | |
| maxResults | No | Maximum total number of matches across ALL scripts (default: 30). Use this to cap total matches, e.g. maxResults=1 to find just the first match. | |
| contextLines | No | Number of lines of context to show before and after each match (default: 1) | |
| caseSensitive | No | When false, matches case-insensitively. Equivalent to grep -i. (default: true) | |
| maxOutputChars | No | Maximum characters to return to the model (default: 6000, max: 32000). Raise only when a single result genuinely needs more; large outputs degrade model performance. | |
| maxMatchesPerScript | No | Maximum number of matches to return per script (default: 3) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden of behavioral disclosure. It implies a read-only search operation and mentions the regex/literal matching behavior, but does not explicitly state side effects, performance implications, or return format. The schema parameters hint at output characteristics (contextLines, maxResults), but the description itself is minimal.
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 with no wasted words. The primary purpose is stated first, and the usage guidance is placed immediately after, making it easy for an agent to parse and act on.
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?
Despite having no output schema, the description combined with the parameter definitions provides enough context for an agent to understand what the tool does and how results are shaped (e.g., via contextLines, maxResults, maxMatchesPerScript). It could be more explicit about the return structure, but for a search tool with detailed schema parameters, it is adequately 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 all eight parameters are documented in the schema. The description adds only a brief clarification of the query parameter (JavaScript regex or literal), which is already present in the parameter descriptions. It does not meaningfully enhance understanding beyond the schema, so a baseline score of 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 action (search), the resource (decompiled Roblox scripts), and the two methods (regex or literal). It explicitly differentiates from the sibling semantic-search-scripts by naming it and specifying the condition that selects it, so an agent can distinguish without inspecting schemas.
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 explicit when-to-use guidance: 'Use for exact identifiers or code patterns' and names the alternative 'use semantic-search-scripts when behavior is known but names are not.' This is direct and leaves no ambiguity about selection criteria.
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 |
|---|---|---|---|
| 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: 20, to avoid overwhelming output) | |
| selector | Yes | QueryDescendants selector. Supports class (Part), tag (.Tagged), name (#HumanoidRootPart), property ([CanCollide = false]), attribute ([$QuestId]), combinators (> >>), OR (,), :not(), :has(). Chain for AND, e.g. Part.Tagged[Anchored = false]. | |
| maxOutputChars | No | Maximum characters to return to the model (default: 6000, max: 32000). Raise only when a single result genuinely needs more; large outputs degrade model performance. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavior on its own. The verb 'Search' and 'QueryDescendants' imply a read-only query operation, which is useful, but the description does not explicitly state that it does not modify instances or describe what a result contains. This is adequate but leaves room for more 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?
Two concise, front-loaded sentences with no filler. The first states the core function, and the second clarifies supported use cases. Every clause earns its place 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?
The input schema fully documents parameters, limits, and output size limits, so invocation is well-covered. However, with no output schema, the description does not describe the return shape or provide guidance on interpreting results. It is minimally viable for a query tool, but not fully complete on its own. Note: the schema description mentions output size behavior, but return value semantics are unexplained, which is a moderate gap. The score reflects sufficient completeness for invocation, not full contextual richness.
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 four parameters clearly. The description adds a general summary of selector capabilities, but does not substantially enrich understanding beyond the schema's parameter descriptions, matching the baseline baseline of 3.
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 searches Roblox instances using QueryDescendants selector syntax, naming the exact resource and query mechanism. It also lists the query categories (class, name, tag, property, attribute), which distinguishes it from broad tree traversal tools like get-descendants-tree or script-focused searches.
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 phrase 'Use for class, name, tag, property, and attribute queries' gives clear guidance on when this tool is appropriate. It does not explicitly mention alternatives or exclusions, so it stops short of a 5, but the intended usage is unambiguous.
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 enriched semantic cards plus exact lexical signals. Use when exact identifiers are unknown; use script-grep for precise text or regex.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of semantic matches to return (default: 5, max: 50). | |
| query | Yes | Natural-language description of the code behavior to find. | |
| minScore | No | Optional minimum dense cosine score. Hybrid lexical matches may still be useful when exact remotes, strings, or APIs match. | |
| indexOnly | No | When true, build or refresh the semantic index and return readiness without searching. | |
| maxOutputChars | No | Maximum characters to return to the model (default: 6000, max: 32000). Raise only when a single result genuinely needs more; large outputs degrade model performance. | |
| requireFullIndex | No | When true, build or complete the semantic index before searching so results are not partial (default: true). |
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. While it mentions semantic and lexical matching, it fails to disclose significant side effects: requireFullIndex defaults to true and may build/refresh the semantic index, and indexOnly can trigger a build without searching. These are important behavioral traits an agent should know before calling.
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 compact sentences with no filler. The core purpose is front-loaded and the usage guidance is delivered in the second sentence, making it easy to scan.
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 and schema together cover purpose, parameters, and routing, but the lack of an output schema and no description of return format leaves a gap. More importantly, the default behavior of building the index is not surfaced in the description, which could lead to unexpected expensive operations.
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 the baseline is 3. The description adds meaning beyond the schema by clarifying that the query can contain exact lexical signals (identifiers, strings) in addition to natural language, which directly informs how to use the query parameter.
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 uses a specific verb ('Find') and resource ('decompiled Roblox scripts'), and clearly states the method ('by behavior using enriched semantic cards plus exact lexical signals'). It also differentiates from the sibling tool script-grep, making the tool's purpose unambiguous.
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 when to use this tool ('when exact identifiers are unknown') and names the alternative ('use script-grep for precise text or regex'). This gives the agent a clear decision rule with no inference required.
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?
Discloses the primary effect (routing to specified client). With no annotations, it carries the full burden; it adequately conveys the side-effect of switching the active client, though does not detail what happens to the previous 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?
Two sentences with no wasted words; the main action is front-loaded, and the prerequisite advice follows naturally.
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 state-changing tool with no output schema, the description sufficiently explains its purpose and prerequisite. It could mention that changing the active client affects subsequent Roblox tool calls, but this is implied.
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 the param is already documented. The description adds value by referencing 'list-clients' for obtaining valid IDs, providing context 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 routes future tool calls to a specified client, with a specific verb ('route') and resource ('future Roblox tool calls'). It distinguishes itself from sibling tools like 'list-clients' by implying its role as the routing setter.
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 instructs to use 'list-clients' first to get available clientIds, providing clear prerequisite and when-to-use guidance.
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?
Discloses the two simulation modes, but lacks details on side effects, permissions, or limitations (e.g., requires focus, works on locked boxes). With no annotations, description carries full burden.
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, 25 words, front-loaded with core action. No wasted 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?
Covers core functionality and modes, but lacks information on error handling, return values, or prerequisites like TextBox existence. Adequate but not comprehensive.
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?
All 4 parameters have schema descriptions (100% coverage). Description adds context by explaining the useKeyPress toggle beyond schema, enhancing meaning.
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?
Clearly states the action (Enter text), the target (Roblox TextBox by path), and distinguishes between two modes (keystrokes vs direct set). No sibling ambiguity.
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?
Implies usage for typing into text boxes, but does not provide explicit when-to-use or when-not-to-use guidance, nor alternatives.
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.
click-buttonexecuteexecute-fileget-console-outputget-data-by-codeget-descendants-treeget-game-infoget-script-contentlist-clientslist-roblox-windowsremote-spyscreenshot-windowscript-grepsearch-instancessemantic-search-scriptsset-active-clienttype-text-box
Add one secure layer between your agents and this server.
