Skip to main content
Glama
okenjioxx

Roblox Executor MCP Server

by okenjioxx
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Simulate a keyboard key press

press-key
Destructive

Simulates a real keyboard press and release in a running Roblox client via VirtualInputManager to trigger input events, movement, or keybound abilities, with optional hold duration.

Instructions

WRITES LIVE GAME STATE. Simulate a real keyboard key press/release in the running client via VirtualInputManager, so anything listening for keyboard input runs: UserInputService.InputBegan/InputEnded, ContextActionService bindings, default movement, and keybound abilities. The key string is resolved against Enum.KeyCode (e.g. 'E', 'Space', 'W', 'LeftShift', 'F'); an unknown name returns a clean error listing what you passed. Sends KeyDown immediately, optionally holds for holdSec seconds (via task.wait) to emulate a held key, then sends KeyUp. NOTE: VirtualInputManager:SendKeyEvent only works from an exploit/elevated context (injected executor thread) — in an ordinary game script it is locked and will error. Getting the service and each SendKeyEvent are pcall-guarded. WARNING: this drives real input into the game and may move the character or trigger abilities. Returns { key, ok, error? }. Signature: { key: string, holdSec: any?, threadContext: number? }. Phase: act; cost=medium; idempotency=contextual-write. Requires: active-client, explicit-mutation-approval. Capabilities: VirtualInputManager. Produces: structured-result. Verify with: assert-state. Safety: MUTATING; writes live game/client state. On failure: inspect tool-schema for exact fields, defaults, constraints, and an invocation example.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
keyYesThe Enum.KeyCode name to press, e.g. 'E', 'Space', 'W', 'A', 'S', 'D', 'LeftShift', 'F', 'Return', 'One'. Case-sensitive and must match an Enum.KeyCode member exactly. Resolved as Enum.KeyCode[key].
holdSecNoHow long (seconds) to hold the key down before releasing it. Default 0 = a quick tap (KeyDown then immediate KeyUp). Use a small positive value (e.g. 0.5) to emulate a held key for charge/hold mechanics. Capped at 10 seconds to avoid blocking the executor thread.
threadContextNoOptional Roblox thread identity for this call; omit it to use the server default.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.0.0-spies.2

TDQS

A4.3/5.0
Behavior5/5

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

Goes well past the annotations: it discloses that VirtualInputManager is locked outside an elevated/injected context and will error, that service acquisition and each SendKeyEvent are pcall-guarded, the KeyDown/holdSec/KeyUp sequencing via task.wait, the 10s cap rationale, and the return shape { key, ok, error? }. The mutating/destructive claims are consistent with destructiveHint=true and idempotentHint=false.

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

Conciseness3/5

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

Front-loading the state-mutation warning is good, but the body is padded with generated metadata that repeats itself — the signature line duplicates the schema, and 'Safety: MUTATING; writes live game/client state' restates the opening warning. High signal-to-noise is undermined by this redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex mutating tool with no output schema, the description covers the critical operational facts: elevated-context prerequisite, pcall guarding, hold timing, and the returned fields. Nothing essential to calling it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the schema already documents all three parameters, so the baseline is 3. The description adds genuinely useful semantics beyond the schema: an unknown Enum.KeyCode name yields a clean error listing what was passed, and holdSec emulates a physically held key for charge/hold mechanics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Simulate a real keyboard key press/release in the running client via VirtualInputManager') and enumerates exactly what fires downstream (UserInputService.InputBegan/InputEnded, ContextActionService, default movement, keybound abilities). That specificity separates it from text-entry and pointer siblings such as type-text-box and click-button.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description conveys strong context for when this is usable ('only works from an exploit/elevated context'), but it never routes the agent between this and near-neighbors like virtual-input, click-button, or type-text-box. Usage is implied by the described effect chain rather than stated as an explicit when/when-not choice.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools