Skip to main content
Glama
okenjioxx

Roblox Executor MCP Server

by okenjioxx
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Game-size profile: instance counts by ClassName

get-instance-counts
Read-onlyIdempotent

Tallies Roblox Instances by ClassName across the descendant tree, revealing place size and composition with heaviest classes first.

Instructions

In-game shape/size profile. Walks game:GetDescendants() once (pcall-guarded, capped) and tallies every Instance by its ClassName, returning the heaviest classes first. This is the quickest way to understand how big and how 'shaped' a place is — e.g. tens of thousands of Parts, a forest of UI Frames, a swarm of scripts, or an unusual pile of a single odd class. The descendant walk is capped (maxScan, default 200000) and sets truncated=true if it hits the cap (the counts then reflect only what was scanned). The returned class list is capped to topN entries. Requires nothing beyond a live game; everything is guarded. Returns { totalInstances, scanned, truncated, distinctClasses, topClasses: [{ class, count }] } (sorted by count desc) or { error }. Signature: { topN: any?, maxScan: any?, threadContext: number? }. Phase: observe; cost=medium; idempotency=read-only. Requires: active-client. Produces: structured-observation, diagnostic-report. Safety: read-only. On failure: inspect tool-schema for exact fields, defaults, constraints, and an invocation example.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
topNNoHow many of the heaviest ClassName buckets to return, sorted by count descending (default 25). The full distinctClasses count is always reported even when the list is trimmed to topN.
maxScanNoMaximum number of descendants to visit (default 200000). The walk stops at this cap and sets truncated=true; raise it for a huge place if you need exact totals, lower it to bound cost.
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.1/5.0
Behavior4/5

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

Annotations already declare read-only, idempotent, non-destructive behavior, so the bar is lower. The description still adds real value beyond them: the pcall-guarded single descendant walk, the maxScan cap, and the truncated=true flag that means counts reflect only what was scanned. It also states read-only safety and error return, though it doesn't quantify expected cost or latency.

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?

Purpose is front-loaded and the examples are useful, but the tail packs redundant schema information (signature, defaults) and metadata boilerplate (phase, cost, produces, requires) that mostly repeats the structured fields already present.

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?

With no output schema, the description carries the burden and does so: it specifies the return object shape ({ totalInstances, scanned, truncated, distinctClasses, topClasses }) and the error case, plus the active-client requirement and truncation semantics. Nothing an agent needs to invoke or interpret it is missing.

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

Parameters3/5

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

Schema description coverage is 100%, so baseline is 3. The description restates maxScan (default 200000) and the topN trim, which the schema already documents in comparable detail, adding little beyond it.

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: walks game:GetDescendants() once and tallies every Instance by ClassName, returning heaviest classes first. This is clearly distinguishable from siblings like get-instance-tree or search-instances, which serve navigation rather than aggregate profiling.

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?

Provides clear context for when it is useful ('the quickest way to understand how big and how shaped a place is'), with concrete examples (parts, UI frames, scripts). It does not name alternative tools or state when not to use it, so it stops short of full routing guidance.

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