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

With no annotations, the description carries the full burden and does unusually well: it discloses the KNOWN BLIND SPOT (only class-declared members; universal node properties absent even from getPropNames), which is exactly the kind of behavior an agent would otherwise get wrong. It does not explicitly state that the call is side-effect-free or describe output shape/pagination, which is why it stops short of a 5.

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?

Well front-loaded: purpose first, then the blind-spot warning, then args. The anecdote about six wrong assumptions in this session is motivating but slightly verbose and consumes lines that could have carried output-shape detail, so it's efficient but not maximally tight.

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 2-parameter read/reflection tool with no output schema and no annotations, the description covers what is returned (declared member names, filtered by pattern), the critical failure mode, and where to go instead. Nothing an agent needs to invoke this correctly is missing.

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 Args block is doing real work: `class_name` is given concrete examples ('Box', 'Editable_Poly', 'VRayLight') and `pattern` is defined as a MAXScript wildcard with default '*' plus a narrowing example ('*segs') and the output-length implication. It stops at 4 because it leaves open edge cases such as invalid class names or case sensitivity, which it flags as a hazard elsewhere but doesn't resolve here.

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?

Opens with a specific verb and resource ('List the members a class DECLARES'), with 'DECLARES' capitalized to signal the scope boundary. It explicitly separates itself from max_check (for node-level universal properties) and max_api_search (which won't find the abstract node class), so an agent can route between siblings without opening schemas.

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 clear directive ('Reflect instead of guessing') plus a concrete when-not: for `name`, `pos`, `wirecolor`, `isHidden`, `isFrozen`, `parent`, `material`, use max_check instead. It also names max_api_search as a non-viable alternative for those cases. This is explicit when/when-not/alternatives guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

With no annotations, the description carries the full burden and does well: it discloses a caching layer keyed per-port, the real cost (~39,700 lines / 1.4 MB, 3.1–5.3 s), and that refresh invalidates the cache. It omits output shape and what happens on zero matches, but the performance/caching profile is unusually well disclosed.

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?

Front-loaded with the core claim, then examples, then an Args block — a clean structure. The parenthetical timings and three separate example invocations are slightly more than strictly needed, but the cost figure is decision-relevant and the examples double as usage guidance.

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?

No output schema exists, and the description sketches returns only loosely ('every class exposing that property + type'), but it covers scope, caching, cost, and all parameters — enough for an agent to decide and invoke correctly.

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 coverage is 0%, so the description must compensate and does: keyword is a case-insensitive substring matched against class and member names, limit caps returned matches, and refresh rebuilds the cache (with the triggering scenario named). All three parameters gain meaning not present in the 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 and resource ('Search the ENTIRE API surface ... classes and members') plus the underlying mechanism (dump `showClass "*.*"` then grep). Concrete example queries make the scope unambiguous and distinguish it from eval/python/scene-inspection siblings.

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?

Explicitly frames when to use it: the only way to answer 'does this Max have VRayLight?' without hallucinating from model memory, plus the refresh-after-install-plugins case. It does not, however, route the agent away from near-neighbors like max_api or max_doc, so no explicit exclusion is given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

With no annotations, the description carries the full burden. It does disclose the key behavioral fact that expressions are genuinely evaluated (not statically inspected) and are processed in order, which is valuable. However, it never warns that evaluation can have side effects — its own example "(Box()).wirecolor" creates a scene object — and says nothing about error handling, timeouts, or whether results include values or just pass/fail.

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?

Front-loaded with the core purpose in the first sentence, followed by a short rationale and a compact example block. Every line contributes, though the "reflection cannot tell you..." sentence could be tightened.

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?

There is no output schema and no annotations, so the description is the only source of truth about returns; it says only that it reports "which ones actually work," leaving unclear whether values, error messages, or partial results are returned. The omission of side-effect caveats is also material for a tool that executes arbitrary expressions.

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 must compensate, and it does: it defines `expressions` as MAXScript expressions evaluated in order and supplies three concrete example strings that convey expected syntax. It omits any guidance on size limits or how many expressions is reasonable.

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 (evaluate/try) and resource (MAXScript expressions) plus the output shape: which expressions actually work. It also names the sibling it contrasts with (max_api) and explains why reflection can't do the job, so an agent can distinguish it from the other max_* tools.

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?

"Run them before writing code that depends on them" gives a clear trigger condition, and the description explains the max_api blind spot that motivates using this instead. It stops short of an explicit exclusion (e.g., when to use max_eval instead of this for actually running production code).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

With no annotations, the description carries the full behavioral burden and does not state whether the operation is undoable, what happens if 'name' collides with an existing node, whether the object is created in the active scene or origin, or what the call returns. The only behavioral nugget is that 'name' is ignored for import, which is useful but thin for a mutation tool.

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?

The purpose is front-loaded in the first sentence and the rest is a compact, tabular mapping of kinds to size keys with zero filler. Every line contributes callable information.

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 4-parameter mutation tool with no annotations and no output schema, the description covers the inputs well but leaves the agent without any statement of return value, error modes, or effect on existing scene state. Adequate to invoke, incomplete for predicting outcomes.

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 must compensate, and it largely does: it defines the kind enumeration, the per-kind size keys (box{w,l,h}, torus{r,r2}, etc.), the [x,y,z] format of pos, and the import payload shape. Remaining gaps are defaults for pos/params when omitted and behavior when params keys mismatch the kind.

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 and resource ('Create a primitive, or import geometry from disk') and enumerates the kind values, so the scope is unambiguous. No sibling in the list performs creation, so the tool is trivially distinguishable from max_delete_objects, max_query_objects, and max_set_property.

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?

There is no guidance on when to use this versus alternatives such as max_file_io for disk operations, nor any prerequisite (scene open, selection state, units). The note about 'import' is a parameter format hint rather than a when-to-use rule, so the agent must infer all routing decisions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

With no annotations, the description carries the full behavioral burden. It usefully discloses that deletions are grouped into one undo block, which tells the agent the operation is batched and potentially reversible as a unit, but it omits permissions, failure behavior for missing names, and whether anything is returned.

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?

The description is two short lines, front-loaded with the action and scope, and every phrase adds information. Nothing is redundant.

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 one-parameter deletion tool with no annotations and no output schema, the description covers the core action and undo grouping but is not complete enough about destructive impact, missing-name behavior, or return values.

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 must compensate, but it only restates that 'names' are node names to delete. It does not clarify array semantics, whether multiple names are supported atomically, duplicate handling, or whether names are leaf names versus full paths.

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?

The description states a specific verb and resource ('Delete nodes') and adds a meaningful scope constraint ('by name inside one undo block'), so an agent can tell this apart from creation, query, or property-setting siblings. It stops short of explicitly naming alternatives or contrasting with them.

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?

There is no guidance on when to use this tool versus alternatives such as max_query_objects or max_set_property, nor any prerequisites or exclusions. Usage is only implied by the verb 'delete'.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

No annotations, so the description carries the burden and does well: it discloses the data source, why it exists (2016 docs retired), staleness caveats, and that results come from a crawled local corpus. It omits the return shape and any performance/rate considerations, keeping it short of a 5.

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?

Front-loaded with the core action and well-organized into rationale, routing guidance, and args. The 'Why local' paragraph is longer than strictly needed but carries genuinely useful provenance context for trusting results.

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?

With no output schema, the description should hint at return values; snippet_chars indirectly conveys that hits include surrounding context, but the overall result shape (pages, ranking) is not described. For a simple read-only search this is nearly complete.

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 must compensate, and it does — query is documented as case-insensitive with concrete examples, limit as max matching pages, snippet_chars as characters of surrounding context. Only defaults and value ranges are left undocumented.

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?

The first sentence states a specific verb and resource — searching a local copy of the MAXScript Reference — and the body makes clear it is prose documentation, not live API reflection, distinguishing it from max_api/max_api_search.

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?

Explicitly names the use case ('how do I use X' / 'what are the arguments of Y') and the alternatives (max_api / max_check) with the condition that selects them ('does THIS Max have it' — prose can be stale, the running process cannot). Nothing is left to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

With no annotations, the description carries the full burden and does so unusually well: code runs verbatim with no wrapper, nothing is auto-saved, no undo block is opened, and writes must be wrapped in `undo "label" on ( ... )` to be reversible. It also discloses that a timeout does not necessarily stop Max, which is a critical operational caveat an agent would otherwise miss.

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?

Front-loaded with purpose, then behavior, then the serialization table, then args — a sensible order. The mapping list is long but each entry conveys a real return conversion; the trailing 'Args' block mildly repeats schema titles while adding genuine semantics.

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?

No output schema exists, so the description supplies the return-value mapping (Integer->number, String->string, Point3->[x,y,z], Array truncated at 2000 items, objects->name). Combined with the undo/autosave caveats, an agent has everything needed to call this correctly.

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 coverage is 0%, so the description must compensate and largely does: `code` is documented as verbatim source requiring `( ... )` wrapping for multi-statement input, and `timeout_seconds` is explained as a give-up point rather than a hard kill. No detail on valid ranges or defaults beyond the schema's 30, which is a small gap.

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 (execute raw MAXScript) and resource (live Max session), plus the return contract. The line 'escape hatch for everything the structured tools do not cover' positions it against the entire family of structured siblings at once.

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 clear selection rule: use this when no structured tool covers the need. It does not name specific alternatives (e.g. when to prefer max_python or max_check over raw eval), so the routing is directional rather than exhaustive.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

With no annotations, the description carries the full behavioral burden, but it does not disclose side effects such as whether import modifies the current scene, whether export overwrites existing files, how merge combines data, or what errors may occur. It adds only the format list and the `selected_only` export scope.

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?

The description is short, front-loaded with the core action, and structured with an Args block. Every line conveys needed parameter information with no wasted text.

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 file I/O tool with no annotations, no output schema, and 0% schema description coverage, the description is too sparse. It should disclose mutation/overwrite behavior, scene effects, and result expectations, none of which are present.

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 must compensate, and it does document all three parameters: action values, an absolute path, and selected_only for export. However, it does not clarify whether `path` is a source or destination per action, whether selected_only is ignored for import/merge, or the default behavior when omitted.

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?

The description states a specific verb-resource combination: import, export, or merge geometry files, with supported formats listed. It is clearly a file I/O tool rather than a scene-query or scene-edit tool, though it does not explicitly name or differentiate itself from any sibling.

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 description lists the `action` values but gives no guidance on when to choose import versus export versus merge, when not to use the tool, or any prerequisites. The agent is left to infer usage context entirely.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does 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.

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

With no annotations at all, the description carries the full disclosure burden and does most of it: it names the Python version, the MaxPlus object API, the fact that Autodesk removed MaxPlus in 2017 so code won't survive an upgrade, the timeout behavior, and the `result` return convention. The main remaining gap is that it says nothing about the execution sandbox, error propagation, or what a timeout returns.

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?

Well front-loaded and sectioned (purpose, when-to-use, result contract, caveats, args), and the benchmark numbers are load-bearing because they justify the routing decision. It runs long, though, and the parenthetical timings could be trimmed without losing the conclusion.

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?

There is no output schema, so the description must explain return values, and it does via the `result` convention plus 'anything JSON-serializable works'. Combined with the upgrade caveat and the performance routing for a two-parameter code-execution tool, an agent has everything needed to call it correctly and interpret the response.

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 coverage is 0%, so the description must compensate, and it does for the critical parameter: it explains that `code` must assign to `result` and that anything JSON-serializable works, which is semantics the schema does not convey. `timeout_seconds` is only glossed as 'how long to wait before giving up' without stating the default or the effect on long scripts, leaving one parameter partly under-explained.

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 and runtime ('Execute Python inside Max (2.7 + MaxPlus)') and explicitly frames itself as 'a second engine, chosen explicitly', which separates it from the MAXScript-based sibling max_eval. An agent can identify the tool's role without opening the schema.

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 'WHEN TO USE THIS' block gives measured criteria for each side of the decision: pure computation/string/dict work goes here, scene traversal and object creation go to MAXScript, reinforced by the blunt instruction 'never drive the scene from here'. It also carves out the MaxPlus-only API case, so the positive and negative conditions are both explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

With no annotations, the description carries the burden and does well: it discloses that scanning short-circuits at `limit` and that `truncated: true` means 'more matches exist' rather than an exact count — a non-obvious behavior an agent would otherwise misread. It does not state read-only safety explicitly, though 'List' and 'Returns' imply it.

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?

Front-loaded with purpose, then return fields, then truncation caveat, then a scannable Args block. Each line carries information an agent needs; nothing is redundant filler.

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?

With no output schema, listing the row fields (name, class, layer, material, verts, faces, pos, hidden, frozen, children) makes the return value predictable, and truncation semantics are covered. Minor gap: no note on cost/perf of scanning large scenes or default-limit rationale.

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 coverage is 0%, so the description must compensate, and it does: every one of the five parameters is documented with syntax examples (matchPattern patterns like "Box*", exact class names, empty = all), a numeric range for limit (1-2000), and paging intent for offset. This is meaningfully richer than the bare schema titles.

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 and resource ('List scene nodes matching a filter') and clarifies the output shape ('compact rows, not full dumps'), which separates it from max_get_object and max_scene_summary. It never names a sibling explicitly, so differentiation is inferred rather than stated.

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 description gives operational context (paging via offset, empty-string means 'all') but never says when to choose this over max_get_object for a single object or max_scene_summary for an overview. Usage is implied by the verb 'List' rather than guided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

With no annotations, the description must carry behavioral burden. It does disclose what is returned (histogram, missing bitmaps, layers) and that it is a whole-scene aggregate, implying a read-only inspection, but it never states that it is non-mutating, how expensive it is, or any permission requirements.

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 sentences plus a one-line arg note; the purpose is front-loaded and every sentence contributes either scope or usage guidance. No filler.

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 single optional-parameter read tool with no output schema and no annotations, the description covers what it returns, why to call it, and what the one parameter does. Only the absence of any read-only/mutation disclosure keeps it from being fully complete.

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 coverage is 0% and the schema gives no description for top_n, so the description must compensate — and it does, explaining that top_n controls how many entries are kept in the class histogram. The only gap is that no default or sensible value range is mentioned.

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?

The description names a specific verb (aggregate) and resource (the whole scene) and enumerates the payload: class histogram, missing bitmaps, layers. That distinguishes it clearly from query/mutation siblings like max_query_objects and max_set_property, though it does not explicitly name a nearest alternative.

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?

"Use this to orient yourself before writing queries" gives a concrete when-to-use condition and implicitly routes the agent away from query tools for orientation. There is no explicit when-not or named alternative, which keeps it short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

With no annotations at all, the description carries the full burden and does well: it discloses the latency tradeoff ('Rendering is slower (seconds)'), the fidelity difference (camera, lights, materials honoured only in render mode), and that the result is an image. It omits any note on whether a file is written, permissions needed, or failure behaviour when no viewport exists.

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?

Front-loaded with purpose in the first sentence, then the usage rationale, then args. Every sentence earns its place; the only mild redundancy is restating the render-mode tradeoff in both the prose and the Args block.

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-optional-parameter, read-only capture tool with no output schema, the description covers purpose, mode selection, cost, and parameter meaning. It says the return is an image, which is the essential output note; remaining gaps (file path, error cases) are minor.

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 coverage is 0%, so the description must document all three parameters, and it does: render's boolean semantics and the critical fact that width/height apply only when render=True. It adds no value ranges or interaction notes beyond defaults, but the mode-dependency clarification is the key gap the schema leaves and it is filled.

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 concrete verb ('Capture') and resource ('active viewport / quick render') plus the return type (image). No sibling tool in the list captures visuals, so an agent can route here unambiguously for a visual check.

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 clear use case: 'verify a change actually looks right instead of inferring from coordinates.' It also explains how to choose between the two modes (instant framebuffer grab vs slower render). It stops short of naming an explicit alternative sibling or a when-not condition, so it lands at 4.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

With no annotations provided, the description carries the full behavioral burden. It usefully discloses that the operation is grouped into a single undo block and lists accepted value types, but it does not explain missing-node behavior, whether all nodes must exist, or what the tool returns.

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?

The description is front-loaded with the core action and undo behavior, followed by concise examples and a compact Args section. Every sentence adds useful information without repetition.

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 with three required parameters, and the description explains how to call it correctly. However, because there are no annotations and no output schema, it should ideally mention return behavior and error handling for invalid nodes or properties.

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 must compensate for all three parameters. It defines names as node names to touch, prop as the MAXScript property name used by getProperty/setProperty, and value as a number, string, bool, or 3-element Point3 list, which is strong semantic coverage.

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?

The description states a specific verb and resource: setting one property on many nodes. It adds the important scope detail that the operation happens inside a single undo block. It does not explicitly distinguish itself from siblings like max_eval or max_api, so it stops short of a 5.

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 examples clarify intended usage for common properties such as wirecolor, name, pos, and visibility. However, the description does not state when to use this tool instead of max_eval or max_api for property changes, nor does it mention exclusions or failure cases.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

With no annotations, the description carries the behavioral burden and does well: it discloses that this checks bridge reachability and reports build, scene, units, timeline, and renderer. It does not explicitly discuss error behavior or failure modes, but for a parameterless status tool the operational behavior is largely clear.

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 short sentences, front-loaded with the core action and followed by the session-level usage rationale. No filler or repetition.

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 parameterless, no-output-schema status tool, the description covers what is checked, what is returned, and why it matters before other calls. Nothing essential for correct invocation is missing.

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 there are no parameter semantics to explain. Baseline for zero-parameter tools applies.

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 operation (check the bridge) and enumerates the reported resources: 3ds Max build, scene, units, timeline, and renderer. This clearly distinguishes a status/diagnostic tool from scene-query or mutation siblings like max_scene_summary or max_set_property.

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?

Explicitly says 'Call this first in a session' and explains why: to determine whether Max is reachable, which scene is loaded, and what units mean for other tools. It does not name alternatives or when-not-to-use cases, but the first-call guidance is clear and actionable.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.