Retrieve full details—transform, modifier stack, material, hierarchy, and bounding box—for a specific 3ds Max object by name, avoiding full scene evaluation.
Full detail for one node: transform, modifier stack, material, hierarchy, bbox.
Cheaper and safer than a max_eval for "tell me everything about this object".
Args: name: exact node name, e.g. "Box001".
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes |
Changes observed during successful MCP inspections.
v0.3.5Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry behavioral disclosure. It does imply non-evaluating, read-only, cheaper behavior by contrasting with max_eval, which is useful. But it does not state what happens for a nonexistent or ambiguous node name, whether results are truncated for heavy scenes, or anything about permissions.
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 compact blocks, front-loaded with the payload description before the argument note. No filler sentences; every clause conveys either returned fields or the max_eval contrast.
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?
The tool is simple (one required param), has no output schema, and the description already enumerates the returned fields plus an argument example, so an agent can call it confidently. Missing only failure-mode behavior for an incorrect node name, which matters for a lookup-by-key tool.
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 0%, so the description has to compensate, and it does: "name: exact node name, e.g. \"Box001\"" clarifies that the value is the literal scene node name rather than a wildcard, pattern, or handle. It stops short of stating case sensitivity or whether instanced/renamed nodes resolve.
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?
"Full detail for one node" pairs a specific verb with a specific resource, and the enumerated field list (transform, modifier stack, material, hierarchy, bbox) tells an agent exactly what comes back. It differentiates from max_eval but says nothing about max_query_objects, the sibling it most plausibly overlaps with.
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?
Gives a concrete use case ("tell me everything about this object") and names the alternative it replaces, max_eval, with a reason (cheaper and safer). It lacks an explicit when-not-to-use case, e.g. using max_query_objects when the name is unknown or when several objects are needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.