Checks the live 3ds Max connection and returns version, open scene path, dirty flag, units, object and selection counts, renderer and listener status.
Check the connection and return Max version, open scene path, dirty flag, units, object/selection counts, renderer and listener status.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |
Changes observed during successful MCP inspections.
v0.2.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the burden; it does signal that this is a connection/state inspection that returns information rather than changing anything. However, it never states outright that it is read-only or non-destructive, nor whether the connection check can fail in a particular way, leaving safety and failure semantics to inference.
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?
A single front-loaded sentence: the action first, then the payload. It is efficient, but the long tail of return fields partly duplicates what the output schema already enumerates, so a few of those clauses add less than they could.
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 zero-parameter, read-only status tool with a declared output schema, the description is essentially sufficient: an agent knows what calling it yields and can rely on the schema for the exact shape. The only real gap is that it does not say when to prefer it over the more targeted query siblings.
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?
The tool takes zero parameters, so the baseline of 4 applies; there is nothing for the description to disambiguate. The enumerated return fields are extra information, though they overlap with the output schema.
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 verb ('Check') plus an enumerated set of returned facts (Max version, scene path, dirty flag, units, counts, renderer, listener status), which makes the resource clear. It is implicitly distinguishable from siblings like max_query_objects and max_layers because it returns environment-level state rather than object lists, but it never names those siblings to draw the boundary.
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?
'Check the connection' hints that this is a good first call to verify the Max session is alive before other operations, but that is left implicit. There is no explicit when-to-use/when-not guidance and no mention of alternatives for narrower queries such as selection or layer inspection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.