Skip to main content
Glama

Observe Studio

observe
Read-onlyIdempotent

Inspect a live Roblox Studio session: read instance trees, properties, logs, scripts, stats, geometry overlaps, player state, and screenshots. Use structured queries to debug and audit builds.

Instructions

Read-only view of Studio. what:

  • status: session, place{placeId,placeName,universeId,creatorType,creatorId}, peers, playtest, capabilities, fps, journal seq.

  • tree: root (game), depth (2, max 6), max (500), classes, fields (extra props) → {nodes:[{path,class,name,n,props?}], truncated} (explicit root always returned).

  • props: paths[], props[] → {items:[{path,class,props}], missing} (unreadable props omitted).

  • find: root, name (substring), class (IsA), tag, attr{name,value}, prop{name,value} → {items, total}.

  • diff: since (seq) → {added[], removed[]} instance paths changed since a cursor.

  • logs: since, level, filter, tail (100), dm ('all' = merged journal, lines carry src) → {items:[{seq,t,level,msg,src}], next}; startup prints of play DMs included.

  • script: path, from, to (1-based lines) → {path, class, lines, total_lines, text} (not cut at 8 KB). stats: fps, frameMs, heartbeatMs, physicsMs, instances, memoryMB. selection: {paths} (edit only).

  • geometry: root (Workspace), max (5000; sampled beyond), tolerance (0.05), include_nested (true) → {overlaps:[{a,b,depth}], nested:[{path,parent}], checked, sampled, ms, totals}: parts intersecting parts, BaseParts under BaseParts. Audit a build; fix all listed.

  • player: dm (client) → name, position, velocity, state, health, walkSpeed, cameraCFrame, floorMaterial, seated.

  • screenshot: the Studio window captured by the bridge (works occluded, un-minimizes without focus). max_width (1024; 0 = none), format jpeg|png, quality (70), region{x,y,w,h} window px, hwnd | title_match → image + {path,width,height,source_width,source_height,scale,windowTitle,hwnd,captured_ms}; image px × scale = window px. windows: lists Studio windows.

  • selftest: the hub's runtime self-check → {ok, checks[]}; use after install or when results look wrong. Prefer structured reads (exact, cheap); screenshots only for visual checks (look answers them in text). dm routes the read into the playtest. response_format 'detailed': ~200 KB cap, full CFrames.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dmNoTarget DataModel: 'edit' (default) | 'server' | 'client' | 'client:N'; logs also accepts 'all' (merged journal)
toNoscript: last line inclusive (default: end)
maxNotree: default 500; find: default 100; geometry: parts checked (default 5000, sampled beyond)
tagNofind: CollectionService tag
attrNofind: attribute match
fromNoscript: first line (1-based, default 1)
hwndNoscreenshot: pin one Studio window (from observe windows)
nameNofind: name substring, case-insensitive
pathNoscript: path of a Script/LocalScript/ModuleScript
propNofind: property match
rootNotree/find: root path (default game); geometry: default Workspace
tailNologs: default 100
whatYes
classNofind: IsA class
depthNotree: default 2, max 6
levelNologs: minimum level
pathsNoprops: instance paths
propsNoprops: property names (default: notable props, ≤ 60)
sinceNodiff/logs: seq cursor
fieldsNotree: extra props per node, e.g. ["Position","Size"]
filterNologs: substring
formatNoscreenshot: default jpeg
regionNoscreenshot: crop in window pixels
classesNotree: keep only these classes
qualityNoscreenshot: jpeg quality, default 70
restoreNoscreenshot: un-minimize without stealing focus (default true)
sessionNoStudio session GUID or unique prefix (default: the active hub; required for writes when several Studios are connected)
wait_msNoWait this long for completion before returning a {job_id,status:"running"} handle (default 25000)
max_widthNoscreenshot: default 1024; 0 disables scaling
toleranceNogeometry: studs of penetration ignored so touching faces are not overlaps (default 0.05)
title_matchNoscreenshot: choose the Studio window whose title contains this (case-insensitive)
include_nestedNogeometry: also list BaseParts parented under BaseParts (default true)
response_formatNoconcise ≈ 20 KB (default) | detailed ≈ 200 KB

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.5/5.0
Behavior4/5

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

Annotations indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false, but the description adds significant detail beyond these: it explains that 'screenshot' works occluded and un-minimizes without focus (with a 'restore' parameter), that 'geometry' samples beyond max and has tolerance for touching faces, that 'props' omits unreadable props, and that 'detailed' response has a ~200 KB cap. These behaviors are not implied by the annotations, so the description adds value. However, some behaviors like rate limits or auth are not mentioned, but not contradictory.

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?

The description is extremely long, listing every mode in bullet points with detailed sub-options. While it is well-structured and front-loaded with the core purpose, it is far from concise. Every sentence does add information, but the sheer volume makes it hard to scan. The formatting helps, but it could be trimmed by relying more on the schema for parameter details.

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?

Given the tool's complexity (33 parameters, 14 modes), the description is remarkably complete. It covers all major modes, explains output shapes, provides defaults, and gives usage tips. It even addresses edge cases like sample thresholds and response size limits. There is no output schema, so the description is the primary source for return value structure, and it handles this comprehensively.

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 description coverage is 97%, so the schema already documents most parameters well. However, the description adds critical context for parameters like 'max' (different defaults per mode), 'dm' (routing), 'wait_ms' (job handle behavior), and 'response_format' (size caps). It also explains that 'script' is not cut at 8 KB, which is not in the schema. Since coverage is high, the baseline is 3, but the extra semantic details justify a 4.

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?

Purpose is clearly stated as a 'Read-only view of Studio' with a comprehensive list of read operations (status, tree, props, find, diff, logs, script, stats, selection, geometry, player, screenshot, windows, selftest). It distinguishes itself from siblings by emphasizing it is read-only, while siblings like 'run' and 'playtest' likely perform actions. The description is specific and resource-oriented, making it easy to identify when to use this tool.

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

Usage Guidelines5/5

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

Provides explicit guidance on when to use different modes, e.g., 'Prefer structured reads (exact, cheap); screenshots only for visual checks (`look` answers them in text).' It also explains when to use 'dm' to route reads into playtest, and mentions 'selftest: use after install or when results look wrong.' While it doesn't name sibling alternatives explicitly, it references the sibling 'look' for visual checks, and the structured reads vs. screenshots trade-off is clearly stated.

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