Skip to main content
Glama
okenjioxx

Roblox Executor MCP Server

by okenjioxx
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

List every player currently in the server (read-only)

get-players
Read-onlyIdempotent

List every player in the running Roblox server with UserId, DisplayName, Team, and AccountAge, and identify the local player. Use it to find a specific player or check team rosters.

Instructions

Enumerate the live roster of the running game by calling game:GetService("Players"):GetPlayers() inside the client and reporting one record per Player. Use this to answer 'who is in this server right now?', to find a specific player's UserId/DisplayName for use in other tools, to see team assignments, or to spot the local player among everyone else. This is a pure read — it does NOT mutate game state and fires no remotes. Each player record contains, every field independently pcall-guarded so one bad property never fails the whole scan: Name, UserId, DisplayName, Team (the Team's Name, or nil when the player is on no team), AccountAge (days), and isLocal (true for the one player equal to Players.LocalPlayer). Requires only the base Roblox API (game:GetService) — no special executor capabilities. Returns { ok, count, localPlayer, players } where localPlayer is the LocalPlayer's Name (or nil), or { error } if the Players service cannot be read. Signature: { threadContext: number? }. Phase: observe; cost=medium; idempotency=read-only. Requires: active-client. Produces: structured-observation. Safety: read-only. On failure: inspect tool-schema for exact fields, defaults, constraints, and an invocation example.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
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?

Annotations already cover read-only/idempotent/non-destructive, yet the description adds substantial extra context: per-field pcall-guarding so one bad property never fails the scan, no special executor capabilities required, no remotes fired, and the exact return shape including the error branch. This is well beyond what structured fields provide.

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-loaded well with the core action and use cases, but the tail is long and partly redundant with annotations (restating read-only, idempotency, cost) plus boilerplate like 'On failure: inspect tool-schema...'. Some sentences could be trimmed without losing information.

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?

There is no output schema, so the description carries that burden and does so fully — it enumerates every returned field (Name, UserId, DisplayName, Team, AccountAge, isLocal) and the envelope { ok, count, localPlayer, players } plus the { error } path. An agent has everything needed to call and interpret it.

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

Parameters3/5

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

Schema coverage is 100% for the single threadContext parameter, so the schema already documents it fully. The description's 'Signature: { threadContext: number? }' merely restates it without adding syntax or default semantics beyond what the schema says.

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 — enumerate the live player roster of the running game — and even names the underlying API call. An agent can distinguish it from siblings like get-local-player-info or discover-player-values without opening any schema.

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

Usage Guidelines4/5

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

Gives concrete triggering questions and tasks ('who is in this server right now?', resolving a UserId/DisplayName, checking team assignments, spotting the local player). It also clarifies it is a pure read, but it never names an alternative sibling (e.g. get-local-player-info) or states 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.

Deploy Server

Other Tools