Retrieve detailed read-only information about any Three.js scene object by name, UUID, or dot path to inspect its properties and structure.
[INSPECT] Read-only. Detailed info about one object by name, uuid, or dot path.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Object name | |
| path | No | Dot path: "Scene.MyGroup.MyMesh" | |
| uuid | No | Object UUID |
Changes observed during successful MCP inspections.
v0.5.0Input schema / additionalPropertiesRemoved value: -falseInput schema / properties / name / descriptionPrevious value: -"Object name (first match)"New value: +"Object name"v0.4.1Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, and the description merely restates 'Read-only' rather than adding context. It says nothing about what happens if multiple identifiers are supplied, whether a missing object errors or returns empty, or any auth/rate constraints — no value beyond the structured fields.
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 tight lines with the category tag first and the purpose second — front-loaded and free of padding. The '[INSPECT]' bracket is slightly cryptic on its own but functions as an efficient grouping cue.
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 3-param detail tool with full schema coverage and safety annotations, the essentials are present, but with no output schema the description gives no hint of what detail is returned, and the multi-identifier ambiguity is left unresolved.
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 each of name, path, and uuid is already documented, and the description's 'by name, uuid, or dot path' simply restates them. Baseline 3 applies; the description does not clarify precedence or mutual exclusivity among the three identifiers.
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 resource (one object) and the three ways it can be addressed (name, uuid, dot path), which is enough to distinguish it from the bulk lookup sibling find_objects. It never names an alternative, so the differentiation is implied rather than explicit.
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 '[INSPECT] Read-only' tag signals the category of use and 'one object' implies single-target lookup, but there is no statement of when to prefer this over find_objects, scene_tree, or geometry_details, and no preconditions are given. Usage must be inferred from the tag.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.