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

No annotations, so the description carries the full burden, and it does disclose the key behavioral fact: the tool returns a nested-list DescID usable as a path in get_params/set_params. It also enumerates the dtype aliases, which tells the agent the accepted type universe. It does not say what happens on duplicate names, whether it mutates the scene, or that it is irreversible, which would have pushed it to 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?

Two sentences: the first states what the tool does, the second states the return value and how to use it. The dtype alias list is brief and formatted as a single comma-separated string. No filler, front-loaded.

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 an 8-parameter mutation tool with 100% schema coverage but no annotations and no output schema, the description covers the essentials: target class, return value, and dtype vocabulary. It omits duplicate-name behavior and confirmation of persistence, minor but real gaps. Overall sufficient for correct invocation.

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 100%, so the baseline is 3 and the schema already documents max/min/step/default/value. The description earns above baseline by listing the dtype aliases explicitly, which gives the agent a quick pre-parse list of valid values without unrolling the schema enum. It does not add meaning to the handle variants, but those are richly described 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 (Add) and resource (a new User Data slot on any BaseList2D), and parenthetically names the use case (rigging / control-exposure pattern). Sibling tools remove_user_data and list_user_data make the create semantics unambiguous.

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?

Names the target class (any BaseList2D) and explains what to do with the result: pipe the returned DescID into get_params/set_params. This is real routing guidance. It does not, however, name remove_user_data/list_user_data or state when not to use it (e.g., if a slot of that name already exists), so it stops short of full when/when-not coverage.

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 substantial work: it discloses that the graph is created on demand by default, that scene-nodes supports creation/connections/port values while queries and labels are material-only, and the id-wiring semantics. It omits reversibility, permissions, and error behavior, so it is strong but not exhaustive.

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-loads the purpose, then uses a compact worked example, then the mode-specific caveats. Every sentence carries information, though the scene-nodes asset-id caveat is a dense run-on that 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?

For a mutation tool with no annotations and no output schema, the description covers syntax, scope, defaults, and the critical asset-id pitfall. It does not describe what is returned (e.g. created node ids despite `$id` being mentioned), which an agent might want when chaining calls.

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 100%, so the baseline is 3, but the description goes beyond the schema by documenting the nested dict grammar ($type, $id, 'thisPort -> childPort' keys, inline port values) and the scope/node_space interplay with concrete examples. The handle types remain largely schema-only.

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 pair (build/mutate) and resource (node graph) plus the mechanism (maxon.GraphDescription declarative dict syntax). It distinguishes the material path from the scene-nodes document path and names the sibling list_graph_node_assets as the source of valid `$type` ids, so an agent can place it among the graph 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?

Gives clear context for the two modes ('scope:"document"' for scene-nodes, default for materials) and warns which asset ids are invalid and where valid ones come from. It does not explicitly say when to prefer a sibling (e.g. set_graph_port for incremental edits) over a full description apply, so it stops short of full when-not 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?

No annotations are provided, so the description carries the full burden; it discloses the underlying operations (CreateNode, GvPort.Connect) and the side-effect that it can create the Texpresso tag when create_tag_if_missing:true. It does not cover atomicity, failure behavior, or permissions, which leaves a gap for an unannotated mutating 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?

Front-loaded with purpose and the sibling differentiation, then the key parameter semantics and example. The alias enumeration is long but earns its place given the schema's vagueness there.

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 complex nested-schema, 4-parameter mutating tool with no output schema and no annotations, the description covers purpose, alternatives, the operator_id format, tag creation, and a usage example. It stops short of return-value/error semantics, but 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?

Schema coverage is 100%, so baseline is 3, but the description adds real value by enumerating the operator_id aliases ('object'|'const'|'result'|...) that the schema only references abstractly as 'short alias'. That mapping is not derivable from the schema alone.

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 ('Declarative builder for an Xpresso ... graph') and explicitly distinguishes itself from the sibling apply_graph_description ('mirror of apply_graph_description but for Xpresso rather than Maxon node materials'). An agent can route between the two without opening either 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?

Names the alternative (apply_graph_description) and the condition that selects this one (Xpresso vs Maxon node materials), and provides a concrete workflow example (Cube -> apply_xpresso_graph -> EventAdd). No explicit when-not or error/prerequisite guidance, so not 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, the description carries the burden and does disclose the core mutation: it creates or updates a Texture tag. However, it does not cover permissions, undo/reversibility, failure modes, or what is returned, leaving meaningful behavioral gaps.

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 three compact sentences with the primary behavior front-loaded. The projection alias list is useful but partly duplicates the schema enum, keeping it just shy of perfect conciseness.

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 an 8-parameter mutation tool with no annotations and no output schema, the description covers the main action and update mode but leaves out side effects, undo behavior, and return information. It is minimally adequate but not 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 description coverage is 100%, so the schema already documents all 8 parameters. The description adds only a high-level note about projection aliases and avoiding TEXTURETAG_* ids, without adding new syntax or usage meaning beyond 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?

The description names a specific verb+resource: 'Link a material to an object by creating a Texture tag'. It also distinguishes this from manually manipulating TEXTURETAG_* parameter ids, making the purpose unambiguous.

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 explains update_if_exists behavior but gives no guidance on when to use this tool versus alternatives like set_params or assign_to_layer. It also omits any when-not conditions or prerequisites.

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 disclose two notable behaviors: passing layer:null clears the assignment, and the target layer must pre-exist. It does not mention permissions, side effects on the target, or overwrite semantics when reassigning, so it is helpful but not complete.

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 tightly written sentences with zero waste. The primary action is front-loaded, followed by the null-clear rule and the prerequisite, in a logical order.

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 two-parameter mutation with no output schema and no annotations, the description supplies the essential behavioral facts an agent needs (clear semantics, pre-existence requirement). Only the reassignment/overwrite behavior and target-kind breadth are left implicit.

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 the schema already documents both parameters, establishing the baseline of 3. The description's note about layer:null duplicates the schema's own 'Layer name, or null to clear' text, and its target examples are actually less complete than the schema's discriminated union.

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 (place/assign) and resource (target on a layer), and distinguishes itself from the creation sibling by noting the layer must already exist. The parenthetical target list (object/tag/material) is narrower than the schema's many target kinds, which slightly under-sells scope, but the core action is unmistakable.

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 precondition: call create_layer first if the layer does not exist. It also explains the null case for clearing. It does not explicitly compare against siblings like set_layer_flags or assign_material, so it stops short of full routing 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 to carry the safety/behavior burden, the description discloses three key behavioral traits: operations apply in order, failures are recorded per-op while the batch continues by default, and the entire batch is wrapped in a single undo group. These details are critical for an agent to predict the tool's side effects accurately.

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?

Three sentences, each dense with information: purpose, execution semantics, and a concrete workflow example. There is zero fluff; every word contributes to understanding or differentiation.

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 composite operation with no output schema, the description fully equips an agent to decide when to use it and what to expect regarding ordering, error handling, and undo behavior. It also addresses the main caveat (nested batch restriction) within the schema, and the workflow suggestion ties into the broader tool ecosystem.

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 the baseline is 3. The description adds value beyond the schema by explaining the op types (through examples of handler names) and hinting at the workflow for populating them. It doesn't detail individual argument structures, but combined with the schema, the agent has sufficient clarity.

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 begins with a specific verb and resource ('Run many generic ops in one RPC'), immediately distinguishing it from singular sibling tools like set_params or create_entity. It also clarifies scope by explaining the sequential application, error handling, and undo grouping, making it unmistakable what this tool does.

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 provides a clear use case ('apply X to all matching entities') and explicitly recommends pairing with list_entities and name_pattern to obtain handles. However, it does not explicitly state when NOT to use this tool or name an alternative, missing the full 'when-not/alternatives' criterion.

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 empty annotations, the description carries the full transparency burden, but it only references the underlying c4d.CallCommand() mechanism and lists example commands. It does not disclose side effects, blocking behavior, potential data loss (e.g., 'Make Editable'), undo implications, or error behavior — significant for an arbitrary-command passthrough.

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 efficient sentences with the verb+object front-loaded. The first sentence states what the tool does; the second narrows scope with useful examples. No wasted words.

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-parameter tool whose schema covers each parameter well, the surface is simple and mostly adequate. However, as a passthrough to arbitrary commands with no annotations or output schema, the description omits warnings about long-running or destructive commands (the schema hints at sync behavior in timeout_ms, not the description), leaving clear gaps for an agent deciding whether to call it.

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 100%, so the schema already documents command_id, subid, and timeout_ms well, including ID examples, discovery via list_plugins, and a default timeout. The description adds marginal value by categorizing built-in commands, matching the baseline 3 when the schema does the heavy lifting.

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 gives a specific verb+resource: 'Invoke a Cinema 4D command by plugin id via c4d.CallCommand()', with concrete examples of the commands it runs (render, save, make editable). It does not explicitly differentiate itself from siblings like modeling_command, render, or preview_render, so it misses the top mark, but the purpose is unambiguous.

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?

No guidance is given for when to pick this tool over the 77 siblings; 'Works for built-in commands ... and any registered command plugin' describes scope of supported commands rather than when to use this tool vs. alternatives like render or save_document. No exclusions, prerequisites, or 'use X instead' hints are provided.

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 it does disclose meaningful side effects beyond the schema: render_data 'copies VideoPosts too', take clones 'copy existing overrides', and it names the underlying operations. It falls short of stating permissions, reversibility, or error behavior.

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, then a compact enumeration of supported kinds and placement rules. It is dense but every clause carries operational detail; the parenthetical implementation notes are slightly heavy but earn their place by clarifying behavior.

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 no-annotation, no-output-schema mutation tool, it covers the supported kinds, placement defaults, side effects, and return value (a handle). Missing only auth/permission context and failure modes, so it 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 coverage is 100%, so baseline is 3, but the description adds value by explaining the `parent` semantics per kind (sibling default for objects, required owner for tags/shaders, host for video_post) and that the clone returns a handle. It largely reinforces rather than duplicates the schema's own parent description, so it edges above baseline.

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 precise verb+resource ('Duplicate an entity') and enumerates the supported entity kinds (object/tag/material/shader/render_data/video_post/take). An agent can immediately distinguish it from create_entity, which makes new entities rather than copying existing ones.

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?

It gives placement guidance ('Objects default to dropping next to the source; pass `parent` to place the clone elsewhere') and per-kind behavior, but never states when to prefer this over create_entity or what prerequisites exist. Usage is implied rather than 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?

The description goes well beyond the destructiveHint annotation by specifying that closing discards unsaved work, the tool refuses without force, and C4D always keeps at least one document open. It discloses the edge case of closing the last document, which is valuable behavioral information an agent cannot infer from annotations alone.

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?

Three sentences with every sentence earning its place: how to identify the document, the force behavior and data-loss warning, and the last-document edge case. The most important information is front-loaded.

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 description covers all key behaviors an agent needs: parameter selection rules, unsaved-change handling, force semantics, and the always-at-least-one-document behavior. With no output schema and a single destructive action, this is sufficient context for correct invocation and user-disclosure.

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 schema already documents each parameter thoroughly (100% coverage), so the baseline is 3. The description adds critical constraint that exactly one of `index` or `name` must be passed, which is not captured by the schema's required fields. This is meaningful extra guidance, though not extensive.

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 clearly states the tool closes an open document, with the precise mechanism of identification (list `index` or `name`) and the constraints. It is immediately distinct from sibling tools like open_document, new_document, and save_document.

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 provides clear operational guidance: pass exactly one identifier, use `force:true` only to discard unsaved changes, and be aware that closing the last document leaves an empty one. It does not explicitly name alternatives or when to prefer save_document over close, so it slightly misses the 'explicit alternatives' bar.

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 well: it states that the tool returns a handle, that object handles include `path` for stable re-resolution, and that the handle can be chained into `set_params` / `set_keyframe`. It does not mention side effects such as immediate document mutation, undo behavior, or failure modes, but it adds substantial useful context beyond the schema.

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 purpose, followed by return behavior and two targeted notes for shader and video_post kinds. Every sentence conveys distinct, useful information without repetition or filler. The structure is appropriate for the tool's complexity.

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 7-parameter, nested-schema constructor with no output schema, the description compensates well by explaining the return handle and its `path` field. Parent requirements are covered in the schema, and the description adds cross-kind routing and alternatives where needed. An agent has enough information to call the tool 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 description coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by explaining kind-specific behavior, such as `kind:'shader'` targeting classical shader chains and `kind:'video_post'` attaching a renderer effect to a RenderData parent. These semantics help an agent choose and populate parameters correctly, though they do not cover every parameter.

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 opens with a specific verb and resource: 'Unified constructor for object / tag / material / shader / video_post.' It also distinguishes the tool from a close sibling by naming `apply_graph_description` for node-material edits. An agent can identify the tool's scope 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?

It gives clear context for `kind:'shader'` (classical shader chains, not node materials) and explicitly routes node-material edits to `apply_graph_description`. It also explains that `kind:'video_post'` attaches effects to a RenderData parent, implying the parent must already exist. However, it does not explicitly mention other sibling creators like `create_render_data` or `create_take`, leaving some routing 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. It usefully discloses that the layer is created at the document layer root and that `update_if_exists` makes the operation idempotent via in-place update. However, it omits what happens on a name conflict without that flag, whether the id is returned, and any permission or side-effect context.

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?

Three tight sentences, front-loaded with the creation semantics and then the configuration parameters. No filler, though the trailing parameter sentence is somewhat redundant with the schema.

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 mutation tool with no annotations and no output schema, the description covers creation, idempotency, and configuration but says nothing about the return value or conflict/error behavior, leaving an agent partially guessing about 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 100%, so the schema already documents name, color, flags, and update_if_exists. The description restates color range and a partial flag list with an ellipsis, adding only marginal meaning beyond the structured fields; baseline 3 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 verb+resource with scope: 'Create a LayerObject at the document's layer root.' The scope detail distinguishes it from generic entity creation, though it doesn't explicitly contrast with sibling layer tools like set_layer_flags or assign_to_layer.

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 idempotent create-or-update behavior implied by `update_if_exists:true` gives some usage context, but there is no explicit when-to-use guidance versus alternatives, nor any statement of prerequisites or when this tool is the wrong choice.

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 discloses that this is a single-call creation operation, names the underlying API, and describes the return value including the reusable `index` handle. It does not state whether an active document is required, undo behavior, or what constraints apply, which are meaningful gaps for an unannotated 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?

Front-loaded with the verb+resource and efficient overall. The middle sentence contrasting with the old workaround is useful routing context but is the most expendable portion; the final sentence on the return handle is well placed.

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 present, the description correctly explains the return value (marker info plus the `index` handle), which an agent needs to chain into set_marker/remove_marker. Only minor gaps remain, such as the requirement for an active document and undo/reversibility behavior.

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 100%, so the schema already documents each parameter, including the frame/time_seconds mutual exclusivity and colour format. The description restates these at a high level (name, frame or seconds, optional colour and length) without adding syntax or format detail beyond the schema, so the baseline 3 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 verb and resource ('Create a named timeline marker') with the key positional variants (frame or time in seconds) and optional attributes, and names the underlying API call. It also distinguishes itself from the old command workaround that only dropped unnamed markers, so an agent can tell it apart from 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?

Clear context: it explains it replaces the seek-and-command workaround and that unnamed markers were the previous limitation, and it points to set_marker/remove_marker as downstream consumers via the returned index. It stops short of explicit when-not-to-use guidance or prerequisites (e.g., an active document), but the usage framing is strong.

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?

Annotations are empty, so the description carries the full burden. It discloses the upsert semantics (update-if-exists) and the return value, which is genuinely useful. However, it does not state behavior on conflict when update_if_exists=false and a name already exists, or any error/permission implications for a mutation tool with zero annotation coverage.

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 two-clause sentence carries the purpose, the upsert behavior, the scope of settings, and the return value with zero filler. Everything earns its place and the central action is front-loaded.

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 12-parameter tool with no output schema and no annotations, the description covers the core purpose, return value, and downstream usage. With full schema coverage carrying parameter meanings, the only meaningful gap is the unspecified behavior when update_if_exists=false collides with an existing name — minor given the required name param provides a natural key.

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% — every one of the 12 parameters has its own schema description — so the baseline of 3 applies. The description only maps the high-level fields (resolution/renderer/fps/frame range) to parameters and adds the handle-return semantics; it does not add syntax or format details beyond 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?

The description states a specific verb+resource ('Create (or update-if-exists) a RenderData') with named fields (resolution/renderer/fps/frame range) in one call. It also names downstream sibling tools (create_take/set_params) for chaining, distinguishing the tool's role from other entity-creation tools in the sibling list.

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?

It hints at usage context by noting the returned handle enables create_take/set_params chaining and that the call consolidates multiple settings 'in one call,' but it never explicitly states when to prefer this over alternatives or when not to use it. No exclusions or alternative-routing guidance 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 must carry the behavioral burden, and it does: it reveals the internal operation composition, the checked-by-default batch-render behavior, and the take-handle return value. It does not cover what happens when a duplicate name exists and update_if_exists is false, but the schema parameter description partially fills in that gap.

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 deliver the core capability, default behavior, return value, and a recommended use case without filler. The primary capability is front-loaded before secondary details, and every clause earns its place.

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 description covers the essential call semantics, the checked default, and the returned handle, which matters because there is no output schema. The main gaps are duplicate-name behavior when update_if_exists is false and any prerequisites for parent/camera/render_data, but the comprehensive per-parameter schema descriptions prevent these from being major omissions.

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 100%, so the schema already documents all nine parameters and earns a baseline 3. The description adds some semantic value by connecting camera/render_data/checked to the SetCamera/SetRenderData/SetChecked operations and explaining checked's batch-render effect, but it is not required to compensate for missing schema info.

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 precise verb-resource pair — 'Create or update a Take' — and lists the exact bundled operations (AddTake + SetCamera + SetRenderData + SetChecked), making it clearly distinct from single-purpose siblings like take_override or create_render_data. It also explains the checked default and the returned handle, further specifying the tool's uniqueness.

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 phrase 'ideal for building per-shot take stacks programmatically' gives a clear use context, and the checked-by-default explanation tells when to pass checked:false. It does not explicitly name alternative tools or state when not to use this tool, so it stops 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?

Annotations already declare destructiveHint=true, so the mutation risk is covered structurally. The description adds the return shape `{removed, track}` and the inclusive-bound semantics of the range mode, which are genuinely useful beyond the annotations; it stops short of noting reversibility or undo availability.

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?

Three tight sentences, no filler, with the primary operation front-loaded and the mode selection second. Every clause carries actionable 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?

With no output schema, the description helpfully declares the return object, and all seven parameters are schema-documented. For a destructive mutation tool it could say more about recovery or undo, but the essential information to invoke it correctly is 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 coverage is 100% so the baseline is 3, but the description adds value beyond the per-field schema text by grouping `frame` versus `start_frame`/`end_frame` into mutually-exclusive operating modes. That mode-level semantics is not derivable from the individual parameter descriptions alone.

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 ('Remove keys from a CTrack') and explicitly distinguishes itself from the sibling set_keyframe as its symmetric counterpart. An agent can identify the operation without inspecting 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?

Clearly routes the caller between the two invocation modes: `frame` for a single deletion versus `start_frame`/`end_frame` (inclusive) for a range. It does not, however, address when to prefer this over siblings like `delete_track` or `get_keyframes`.

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?

destructiveHint=true already covers the safety profile, and the description is consistent with it. It adds useful context that the whole track (not individual keys) is removed and that the result is `{removed: bool}`, but says nothing about reversibility, undo, or side effects on existing keyframes.

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 sentences, front-loaded with the action and identifier, closing with the return shape. 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?

Acceptable for a destructive mutation: the target identity and return value are covered and no output schema is needed. However, with no annotations beyond destructiveHint and no usage context, an agent lacks guidance on when this is the correct tool versus delete_keyframe.

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 the schema already documents handle, param_id, and component. The description restates the identity rule (param_id + optional component) but adds no format or edge-case detail beyond it, matching the baseline 3.

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 (Remove) and resource (an entire CTrack), plus its identifier (param_id + optional component). It implicitly separates itself from delete_keyframe by emphasizing 'entire track', though it never names that sibling explicitly.

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?

No when-to-use guidance, prerequisites, or alternatives are given. An agent must infer that this is the track-level counterpart to delete_keyframe rather than keyframe-level deletion, since the description never routes between them.

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?

readOnlyHint=true already tells the agent this is a safe read, so the bar is lower; the description adds real value by disclosing the exact shape of the payload (id, name, cycle enum, current value), which matters because there is no output schema. It says nothing about ordering, pagination, or failure modes for an unresolvable handle, keeping it from 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?

Two tightly packed sentences with no filler; the purpose and the returned field list are front-loaded before the usage instruction. Every clause earns its place.

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 compensates by listing the returned fields, and the handle's complexity is fully covered by the schema. A mutation-free read tool with readOnlyHint and a fully documented parameter needs little more; only error/empty-handle behavior is unaddressed.

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% and the single handle parameter is exhaustively documented with all its discriminated shapes plus guidance to prefer path over name. The description only restates 'resolved by handle', adding no syntax or format detail beyond what the schema already carries, so the baseline 3 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 verb ('Dump') and resource ('all description parameters ... of a C4D entity resolved by handle') and even enumerates the returned fields (id, name, cycle enum, current value). An agent can distinguish this from get_params/set_params without opening a 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?

'Use this to discover parameter IDs before reading/writing' gives a clear triggering context and implicitly routes to get_params/set_params as the follow-up. It stops short of naming those siblings explicitly or stating when NOT to use it, so it is short of a full 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?

readOnlyHint=true already establishes this is a safe read. The description goes well beyond that by disclosing what the traversal captures (type_id/type_name/name per node), the Xbitmap-to-'file' promotion, the heuristic 'file_candidates' detection, and the 'linked_shaders' expansion for Fusion/Colorizer whose internals are invisible via GetDown. That is meaningful behavioral context about output shape and known traversal blind spots, but with no output schema and no statement of size/rate limits, it stops short of a 4-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, then the applicability boundary, then output details. Dense but each clause carries distinct information (field names, heuristics, link expansion). Slightly long for two sentences, but 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?

No output schema exists, so the description must carry the return-shape burden — and it does, enumerating the file/file_candidates/linked_shaders fields the consumer will see. Combined with the sibling routing and handle-style hint, an agent has everything needed to invoke it 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 100%: the schema not only names both parameters but explains the handle shapes and even states 'For this tool, pass a shader handle such as {kind:"shader", owner:<material handle>, index:0}'. The description's 'resolved from a handle' adds only mild reinforcement, and max_depth is left entirely to the schema. Baseline 3.

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+resource+scope ('Recursively dump a shader (resolved from a handle) into JSON') and explicitly delimits itself against the sibling tools list_graph_nodes / apply_graph_description for node materials. An agent can distinguish this from get_container or get_params without opening a 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?

Gives an explicit when-not ('Classical materials only — node materials ... use list_graph_nodes / apply_graph_description instead') and a discovery hint ('Pair with list_entities kind=shader to discover shader handles'). Both the applicability boundary and the entry workflow are stated.

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 readOnlyHint=true already covering the safety profile, the description adds real behavioral value: it discloses that hidden keys exist and gives a concrete example (Octane AOV shader slots at 3740/3741), which is not derivable from the schema or annotations. Output volume/pagination is not discussed, keeping it from 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?

Two tight sentences, front-loaded with the core action and the distinguishing detail, no filler. Every clause earns its place.

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 read-only dump with no output schema, the description conveys enough: what is returned (raw container contents including hidden keys) and how to narrow it. It would be stronger with a note on output size or formatting, but it is adequate.

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 id_from/id_to are fully documented as inclusive bounds in the schema itself. The description only restates the filtering intent ('Filter by key range to narrow output') and adds no syntax or semantics beyond that, so baseline 3 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 verb (dump) and resource (raw BaseContainer of a C4D entity), and explicitly contrasts with the sibling `describe` by noting hidden keys that describe omits. An agent can distinguish this from describe/get_params 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 parenthetical establishes when this is preferred over `describe` (when hidden keys matter), and the second sentence advises narrowing via key range. It stops short of an explicit when-not rule, but the usage context is clear.

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?

Annotations already declare readOnlyHint=true, and the description does not contradict this. It adds behavioral context by specifying that it returns canonical handles and a marker_count, and notes it is a one-shot read (no pagination). This exceeds the annotation coverage and gives the agent expected output shape, though it stops short of detailing exact return types or error behavior.

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 sentences with zero filler. The first sentence front-loads the purpose and enumerates the returned fields; the second sentence provides the sibling and writer counterparts. Every clause earns its place, making it both concise and well structured.

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 getter with no output schema, the description covers all essential return fields (fps, range, handles, marker_count) and links to related tools for further actions. It is complete for an agent to invoke correctly and interpret the result without additional context.

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?

With zero parameters, the schema coverage is trivially 100%, so the description is not required to document parameters. Per the rubric, a 0-parameter tool gets a baseline score of 4. The description appropriately focuses on output semantics rather than inputs, adding value without redundancy.

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 clearly states the tool reads key document fields (fps, frame range, current frame, etc.) and explicitly distinguishes it from related siblings by mentioning list_markers for marker listing and set_document as the writer counterpart. This leaves no ambiguity about what the tool does or how it differs from similar 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?

The description implies usage context by calling it a 'one-shot reader' and points to list_markers for listing markers and set_document for writing, giving a clear sense of when to use this tool. However, it doesn't explicitly state 'use this when you need the current state in one call' or mention exclusions, but the intent is clear enough for an agent to pick the right tool.

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?

Annotations already declare readOnlyHint=true, so safety is covered. The description adds real behavioral value by disclosing what the call returns (available node spaces, the active one, the alias table) and that addressability is build/material dependent. It does not cover error behavior or output shape, keeping it below 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?

Two sentences, front-loaded with the return content, followed by the usage directive. No filler or restatement of the name/title.

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 read-only, single-parameter introspection tool with no output schema, the description covers what is returned and the prerequisite use case. It stops short of describing the alias table's structure or the failure mode when a node_space is not addressable.

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% ('Material handle.'), so the schema already documents the sole parameter. The description adds no further detail about the handle's accepted forms (object/material/tag/etc.), so baseline 3 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 verb (report) and precise resource (node spaces a material exposes, the active one, and the alias table). It is clearly distinguishable from siblings like list_graph_nodes (which enumerates nodes) and apply_graph_description (which mutates).

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 ordering relationship and alternative: 'Use this before `apply_graph_description` to confirm the right `node_space` is addressable.' The agent knows exactly when to call this tool relative to its sibling.

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?

Annotations only declare readOnlyHint=true. The description adds real behavioral value by disclosing the return shape `[{frame, value, interp}]` (no output schema exists) and the inclusive range-clipping semantics of start_frame/end_frame. It doesn't cover error/auth behavior, but most of the burden is met.

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?

Three compact sentences, front-loaded with the core action before the workflow hint and return shape. No filler or repetition of the title.

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 read-only tool with full schema coverage and no output schema, the description supplies the missing return-format and range semantics. An agent has everything it needs 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 description coverage is 100%, so the baseline is 3. The description reinforces the param_id/component pairing concept and the inclusive clip behavior, but the schema already documents fps, component, start_frame, and end_frame in equal or greater detail, so marginal added value is limited.

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 ('Read the keys on a specific animation track'), which cleanly distinguishes it from siblings like set_keyframe, delete_keyframe, and get_params. An agent can identify its 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?

Gives a clear usage path: 'Combine with list_tracks to discover which (param_id, component) pairs are animated,' which tells the agent when this tool is needed. It stops short of explicit when-not-to-use or naming alternatives to get_keyframes itself.

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?

Beyond the readOnlyHint annotation, it discloses the 50,000 point/poly cap, why it exists (JSON payload protection), how to override it, and the exact return layout for triangles vs quads. It does not say what happens when the cap is hit (truncation vs error), which keeps it below 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?

Three tight sentences, front-loaded with the core action and supported types, followed by prerequisites, return format, and limits. No filler, though the parentheticals make it dense.

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 and only a readOnly annotation, the description carries the full load and does so: it covers supported object types, the conversion prerequisite, return value structure, and size limits. Nothing material is missing for correct invocation.

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 all four parameters are already documented, including the 50000 defaults and the 'normals'/'selections' semantics. The description adds only the rationale for the caps, so the baseline 3 is warranted.

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 opens with a specific verb+resource ('Read points and polygons (or spline segments)') and names the exact supported types (PointObject/PolygonObject/SplineObject). It is immediately distinguishable from the write-side sibling set_mesh.

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?

It gives a concrete prerequisite — primitives must be converted first via `modeling_command` make_editable — which is real when-to-use guidance tied to a named sibling. It does not explicitly state exclusions or contrast with get_params/describe, so it stops 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?

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds that the result is null when no layer is assigned, which is useful return behavior beyond annotations, though it doesn't cover errors or entity-not-found handling.

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?

One compact sentence, front-loaded with the action and result, with 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-parameter getter with annotations and no output schema, the description covers the essential read-only retrieval and null case. It is slightly incomplete because it doesn't clarify the returned layer format and its parenthetical examples don't match the full schema union.

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 the target parameter is already fully documented as an anyOf union. The description adds only an incomplete example list '(object / tag / material)' while the schema supports many more kinds, so it does not meaningfully improve on the structured field.

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 (Return) and resource (layer currently assigned to a target entity) and notes the null case. It does not explicitly differentiate from siblings like list_layers or assign_to_layer, so it falls short of the top score.

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?

No guidance on when to use this getter versus list_layers, assign_to_layer, or create_layer. The null-if-unassigned note is behavioral context, not usage 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?

Annotations already declare readOnlyHint=true, so safety is covered. The description adds real behavioral value beyond that: it specifies the return shape `{values: [{path, value}]}` in request order and the dtype-inference behavior, which the annotations do not carry.

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-loads the core purpose, then packs id formats, dtypes, and return shape into dense but non-redundant sentences. Every clause earns its place, though the id-format enumeration is dense enough to require careful reading.

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 carries the return-value burden and does so explicitly. Combined with the return shape, dtype rules, and the describe pointer, an agent has everything needed to call it 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 100%, so the schema already documents the id/handle types. The description nevertheless adds meaning the schema doesn't: the int vs chained-list vs x/y/z sub-component semantics, the explicit dtype escape hatch, and the position.x example. This is above the baseline 3 for high-coverage schemas.

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+resource ('Read parameter values on a C4D entity') and implicitly contrasts with set_params (write) and describe (discovery). An agent can distinguish it from the write sibling and the discovery sibling 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?

Explicitly routes the agent to `describe` for discovering ids, which is the key prerequisite before calling this tool. It stops short of naming when-not-to-use conditions (e.g. vs set_params or get_container), so it's clear context but not full when/when-not/alternatives coverage.

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?

Annotations provide readOnlyHint=true, so an agent already knows it's safe. The description then adds value by disclosing the returned data types (active object as primary, all selected objects, active tag/material) and the guarantee that handles are canonical and can be piped into other tools. It doesn't go deeper into rate limits or error cases, but it doesn't need to.

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?

Three sentences, all dense with information: what you get, why it's useful, and a note on output format. No filler, no restating of the tool name.

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 query, the description is complete. It captures the return values and the primary use case (reacting to user's current focus). It could theoretically describe the data shape in more detail, but given the lack of output schema, the description does enough.

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 0 parameters and the schema coverage is 100%, so there is no ambiguity. The description even mentions the underlying mechanism (canonical handles) that makes the output useful for chaining. Nothing is left undefined.

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?

Uses a specific verb+resource combination ('Read the active document's current selection') that clearly defines both action and scope. Names the primary entity, the full selection set, and two special cases (active tag, material), which distinguishes it from generic 'get' tools. The phrase 'without asking them to re-pick entities' positions it against interactive workflows.

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?

Delivers clear context: it is for reading the current selection and piping into describe/set_params/etc. This implies when it's the right tool (selection-reading) and names follow-on tools. The exclusion is inferable from context rather than explicit 'use X instead,' so it misses a full 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, the description carries the behavioral burden. It usefully discloses the return of newly-imported top-level objects and optional re-parenting/renaming, but omits key mutation side effects for a scene-modifying tool: whether existing scene content is preserved, undo behavior, and required document state.

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?

Three tight sentences, front-loaded with the operation, then return/chaining, then optional modifiers. Every clause earns its place and 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 4-parameter merge tool with no output schema or annotations, it covers the core operation, return value, chaining, and optional behaviors well. It still leaves gaps around error conditions, supported format nuances, and the exact shape of returned objects, so it is strong but not fully exhaustive.

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 the schema already documents all four parameters. The description restates parent and rename effects with slightly more workflow context (re-parents top-level objects, renames first root) but adds no syntax or format details beyond the schema, so the baseline 3 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 verb (Merge/Import), resource (external abc/fbx/obj/c4d files), and destination (active document) via MergeDocument. It also names the returned top-level objects and chaining with set_params/create_entity/create_take, clearly distinguishing it from creator 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?

Describes the intended workflow of importing into the active document and then chaining the returned objects, plus optional re-parenting and renaming. It does not explicitly distinguish merge from open_document/new_document (when to replace vs merge), so it stops short of full when/when-not 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?

The annotations already declare readOnlyHint=true, so the read-only nature is covered. The description adds valuable behavioral context by detailing the returned fields, especially that the list index is the handle accepted by set_active_document and that active-document status is included. This goes beyond what the annotation alone conveys.

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?

Three sentences with no wasted words: the first states the action, the second defines the output, and the third gives the contrasting sibling. The most important information is front-loaded.

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 enumeration tool with no output schema, the description fully equips an agent to call it correctly and interpret the result. It explains the index handle, the fields, and how it relates to set_active_document and get_document_state. Nothing essential 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?

There are zero parameters, so the schema imposes no ambiguity and the baseline is 4. The description does not need to explain any parameters, and it correctly focuses on output semantics instead.

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 uses a specific verb ('Enumerate') and resource ('documents currently open in Cinema 4D'), and lists exactly what each entry contains: index, name, path, and active status. It also distinguishes itself from get_document_state, which only reports the active document, making the tool's role within the sibling set clear.

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 explicitly states when to use this tool instead of an alternative: 'get_document_state only reports the active document; this is how you discover the others before switching.' This gives the agent a concrete decision rule and names the alternative tool directly.

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 readOnlyHint already declaring safety, the description adds substantial behavior: what each summary contains, kind-specific fields (is_active), that include_tags/include_params read data inline in one call, and the shader-chain caveat. That is real disclosure beyond the annotation.

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 and return shape, then usage, then the shader caveat in bold. Dense but nearly every clause carries information; the parenthetical example is slightly long but illustrative rather than 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 an 11-parameter tool with no output schema, the description covers return shape, filtering semantics and when to prefer siblings, which is close to complete. Minor gaps remain (e.g. the owner handle requirement is left entirely to the schema, and no pagination/size limits are mentioned).

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 100% so the baseline is 3, and the description adds genuine meaning on top: it explains the kind=object filters (type_ids/tag_types/max_depth) as a group and clarifies the inline-read behavior of include_tags/include_params, with a concrete worked example. It does not restate syntax beyond the schema, which is appropriate.

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+resource ('Enumerate scene entities of a given kind') and immediately characterizes the return payload. It distinguishes itself from nearby siblings like list_graph_nodes and describe by naming them in context.

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 routes the agent: 'Use this first to find what exists before describe/set_params', plus an explicit exclusion ('for node-material graphs use list_graph_nodes'). It also names the condition that makes inline reads preferable to exec_python.

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?

Annotations already declare readOnlyHint=true, so the safe-read nature is known. The description adds meaningful behavioral details beyond that: the filtering behavior specific to the scene-nodes space, and the fact that `supported:false` is returned when the build lacks the maxon framework. These are operational quirks an agent would otherwise not know, so the description adds real value.

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?

Three sentences with zero fluff. The first sentence states the core purpose and ties it to a specific use case. The second adds a domain-specific nuance about filtering, and the third covers an edge-case response. Every sentence earns its place, and the most critical info (purpose and usage) is front-loaded.

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 read-only listing tool with one parameter and no output schema, the description is essentially complete: it explains what the tool returns, how to use the results, a special case (scene-nodes filtering), and a failure indicator (`supported:false`). The only thing missing is a precise description of the output format, but that may be implied by the tool's nature and the absence of an output schema. An agent has enough to call this tool 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?

The single parameter `node_space` is fully described in the schema (100% coverage) with its alias options, default value, and acceptance of fully-qualified maxon.Id. The description does not add new semantic details about the parameter itself—it only explains how the parameter value affects filtering, which is more of a behavioral note. Since the schema already covers parameter meaning, a baseline 3 is appropriate.

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 clearly states the verb 'enumerate' and the resource 'node-template asset ids for a node space', and immediately ties it to the `$type` parameter in `apply_graph_description`. It explicitly distinguishes these ids from the `net.maxon.corenode:*` ids reported by `list_graph_nodes`, making it easy for an agent to tell the two tools apart without inspecting 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?

The description provides concrete usage context by specifying that the returned ids are what you pass to `apply_graph_description` as `$type`. It also notes that results for the scene-nodes space are filtered to addable templates, giving the agent a condition to watch for. It doesn't explicitly say 'use this when you need X and not when you need Y', but the sibling differentiation and use-case tie make the intended usage clear enough.

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?

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description goes beyond that by disclosing the failure mode ('supported:false' when the maxon framework is unavailable or no graph exists) and the flat-list return shape, which is genuinely useful edge-case context.

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?

Three tightly written sentences with the core action front-loaded and no filler. It could be marginally tighter but nothing is wasted.

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 read-only listing tool with no output schema, the description covers purpose, both targeting modes, return shape (flat list), and the failure case. What a caller needs is largely present; only node_space handling is left entirely to the schema.

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 parameters are already documented; baseline is 3. The description clarifies the handle-vs-scope relationship but adds no detail on 'node_space' values or handle sub-kinds beyond what the schema already states.

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: 'Walk a node graph and return a flat list of nodes,' and clarifies the two target spaces (material via handle, or the scene-nodes graph via scope:'document'). This distinguishes it from siblings like list_xpresso_nodes and get_graph_info by graph type, though it never names an alternative explicitly.

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?

It implies usage by explaining that you target either a material handle or the document scene-nodes graph, which is directional, but there is no explicit when-to-use vs when-not or routing to a sibling tool. Usage guidance is inferable rather than stated.

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 readOnlyHint=true annotation covering the read-only nature, the description adds value by detailing the exact return structure—name, optional color, and the full flag dictionary. This goes beyond the annotation and clarifies what the agent can expect, though it does not discuss any exceptions like empty documents.

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 sentences with no filler. The first sentence states the core purpose, and the second lists the return contents. Every element is necessary for understanding the tool, making it efficiently structured and front-loaded.

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 simple enumeration tool with no parameters and a read-only annotation, the description provides sufficient information: what it does and what it returns. It omits edge cases like an empty document, but for a list operation this is a minor gap and the overall context is complete enough.

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 has zero parameters, so the schema is trivially complete. The description correctly avoids redundant parameter explanations, which meets the baseline 4 for tools with no parameters.

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 clearly states the action (enumerate) and resource (every LayerObject in the active document), and specifies the return fields. It distinguishes itself from siblings like get_object_layer by focusing on all layers rather than a single object's layer, though it does not explicitly name alternatives.

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 implies usage for retrieving all layers, but it provides no explicit guidance on when to use this tool versus related ones like get_object_layer or set_layer_flags. The context is not spelled out, leaving the agent to infer the appropriate scenario.

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?

The readOnlyHint annotation already covers the safety profile. The description adds behavioural detail about the enumeration (GetFirstMarker + GetNext) and the exact fields returned, plus the index handle. This is more than the annotation provides, though it doesn't discuss performance or edge cases. Since the tool is a simple list, this is sufficient.

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 sentences, front-loaded with the core purpose and output details, then the usage guidance. Every sentence earns its place with no redundancy or fluff. It's concise and well-structured.

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 tool with no parameters, no output schema, and a read-only annotation, the description provides all necessary context: what it returns, the index handle for further operations, and when to use it. The agent can call this tool correctly without needing additional information.

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 has zero parameters, so the schema is empty and schema coverage is 100% by default. The description naturally adds nothing about parameters. As a baseline for no-parameter tools, this is appropriate; the description instead focuses on the output, which is the main semantic content.

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 clearly states the tool's purpose: to enumerate every timeline marker in the active document, listing specific fields (frame, time_seconds, name, colour, length_frames) and even notes the underlying API. It distinguishes itself from get_document_state by mentioning that get_document_state only reports marker_count, making it evident when this tool is appropriate.

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?

It explicitly states when to use this tool: 'Use this to verify marker placement' and contrasts it with get_document_state. This gives the agent a clear decision rule for selecting between sibling tools. The mention that the index handle is accepted by set_marker/remove_marker also informs downstream usage.

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?

Annotations only give readOnlyHint=true; the description adds real behavioral context: the bridge forces a scene pass to populate the MoData array before sampling, and it discloses the supported:false failure conditions. This is exactly the kind of detail that goes beyond 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?

Four tight sentences, each earning its place: purpose, internal mechanism, return shape, and failure mode. Front-loaded with the verb and resource.

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 carries the return contract and does so explicitly ({count, returned, clones:[{index,pos,matrix?}]}). Combined with the supported:false semantics, an agent has everything needed to call and interpret it.

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 handle, max_count and include_matrix are already documented in the schema. The description adds only the 'matrix?' optionality of the return items, so the baseline 3 applies when the schema does the heavy lifting.

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 (Read) and resource (per-clone transforms from a MoGraph generator), and names concrete generator types (Cloner / Matrix / Tracer). An agent can immediately distinguish this from mesh/transform siblings like get_mesh or sample_transform.

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?

Explains applicability to MoGraph generators and the failure case (supported:false when the build lacks c4d.modules.mograph or the handle isn't a generator), which is useful context. However, it never states when to prefer this over alternatives such as sample_transform, leaving the agent to infer the routing.

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?

The readOnlyHint annotation already declares the tool is read-only, so the description does not need to repeat that. The description provides some details about the return structure (plugin and plugin_file fields) but does not mention error handling or empty results. This is acceptable for a simple list operation.

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 concise and to the point. Two sentences cover the tool's purpose and parameters without unnecessary fluff. The structure is logical, starting with the overall function and then detailing usage.

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?

Given the lack of an output schema, the description does a decent job of explaining the return fields. It does not mention potential errors or edge cases, but for a list/filter tool it is reasonably complete. More details on the exact format of the result (e.g., array vs. object) would improve completeness.

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 schema descriptions cover all parameters clearly. The description adds helpful context, such as the plugin_type can be a string alias or raw integer, and gives examples for plugin_pattern. This complements the schema without redundancy.

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 clearly indicates that the tool lists plugins and allows filtering by type and patterns. It mentions the output fields, so the purpose is well understood, though it could be slightly more explicit about returning a list.

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 explains how to use the tool (pass plugin_type, name_pattern, plugin_pattern) but does not provide guidance on when to choose this over other list tools. It says 'Generalized' which hints at its scope, but lacks explicit alternatives.

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?

Annotations already declare readOnlyHint=true, so safety is covered. The description adds real behavioral detail beyond that: the exact per-track payload fields and the non-obvious behavior that vector tracks (Position, Rotation, Scale) surface as separate per-component entries rather than one entry.

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?

Three tight sentences, front-loaded with the action and target, then the return shape, then the one edge case. No filler or restated title.

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 usefully enumerates the returned keys and the vector-track splitting rule, covering what an agent needs to consume the result. Ordering or volume characteristics of the list are not mentioned, a minor gap.

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% for the single handle parameter, so the baseline is 3. The phrase 'the resolved entity' hints that the handle must resolve to a live entity but adds no format or resolution detail beyond the schema's own description.

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 (Enumerate) and resource (CTracks) scoped to the resolved entity, and the return-shape sentence makes it unmistakably the track-listing tool rather than get_keyframes or delete_track. An agent can distinguish it from siblings 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?

Explicitly gives downstream usage context: results are meant to be piped into get_keyframes / set_keyframe, which tells the agent where this fits in a workflow. It stops short of stating when NOT to use it or naming an alternative lister for other entity kinds, so it lacks full exclusion 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?

readOnlyHint=true already declares this is a safe read, so the safety burden is off the description. It adds real behavioral value beyond the annotation by disclosing the per-entry return shape `{desc_id, name, dtype, value}` and the contract for reusing `desc_id` as a DescID path elsewhere.

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 sentences, both load-bearing: the first defines the operation and its result, the second defines how the result is consumed. Front-loaded and free of 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, the description correctly compensates by specifying the returned fields and the desc_id reuse path. For a single-parameter, read-only list tool this is nearly complete; only the accepted handle kinds and any empty-result behavior are left unstated.

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 the baseline is 3. However the schema is a large 10-variant anyOf union of handle kinds with almost no prose per variant, and the description adds nothing about what a valid target handle looks like or which kinds are accepted.

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 ('Enumerate'), the exact resource ('User Data slots'), and the scope ('on a target'). It is trivially distinguishable from its obvious siblings add_user_data and remove_user_data without opening any 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 second sentence gives concrete downstream usage: feed the returned `desc_id` into `remove_user_data` / `get_params` / `set_params`. That tells the agent why and where to use the output, though it never explicitly states when to prefer this tool over a direct get_params call or states any exclusions.

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 readOnlyHint=true already covering the safety profile, the description adds genuinely non-obvious behavior: the stable dotted-index path id scheme ('0.2' decoded explicitly) and the handle-resolution rule that an object handle uses that object's first Texpresso tag. It also notes the return carries port summaries. It stops short of noting ordering guarantees or error behavior on a non-Xpresso tag.

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?

Three sentences, front-loaded with the core action, then return shape, then consumption target. Every sentence earns its place, though the id-format and handle-taking-tool sentence is dense and could parse more crisply.

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 read-only discovery tool with no output schema, the description adequately covers what comes back (flat GvNode list, ids, port summaries) and what to do with it. Minor omission: no statement of ordering, root-node inclusion, or behavior when a tag has no Xpresso graph.

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?

Only one parameter and schema coverage is 100%, so the baseline is 3, but the description meaningfully extends the schema by explaining the anyOf duality: a tag handle (Texpresso) OR an object handle, with the implicit first-Texpresso-tag fallback. That is semantic value the schema's 'Xpresso tag handle or host object handle' only hints at.

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 and resource ('Walk an Xpresso (Texpresso / GvNodeMaster) tag and return a flat list of its GvNodes') and specifies the shape of each entry (dotted-index id plus port summaries). This is specific enough to distinguish it from the sibling list_graph_nodes/list_markers family without opening a 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?

It gives clear downstream context: the returned id is what you feed to apply_xpresso_graph, set_xpresso_port, remove_xpresso_node, or any handle-taking tool via {kind:'gv_node', tag, id}. That establishes when this tool belongs in a workflow, but it never states when NOT to use it or contrasts it against the node-graph siblings.

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 are provided, so the description carries the full burden. It discloses a key behavioral trait: which commands return new handles vs mutated targets, which is valuable. However, it doesn't mention permissions, failure modes, or whether commands can fail/destructive implications of operations like 'melt' or 'collapse'.

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, then behavior split, then aliases. The alias list is long but necessary for invocation. Slight over-length due to the extensive alias enumeration, but every sentence earns its place.

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 tool with no annotations and no output schema, the description covers purpose, behavior, and invocation aliases well. It could go further on return value shape (it mentions handles vs mutated targets) but doesn't explain output structure, though no output schema exists to compensate.

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 the schema already documents all 4 parameters including the mode enum default and params container. The description adds little parameter-level detail beyond cross-referencing the alias list, which is baseline for full-coverage schemas.

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 ('Run a Cinema 4D modeling operation via c4d.utils.SendModelingCommand') and enumerates the exact operations (Current State to Object, Connect/Join, Split, etc.). This clearly distinguishes it from siblings like call_command or set_mesh.

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?

It lists commands and their behavioral categories (geometry-producing vs in-place), which implicitly helps selection, but never states when to prefer this tool over alternatives like call_command or set_mesh. No explicit exclusions or alternatives are named.

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 load and does well: it discloses the mutual-exclusion constraint, the kind-matching precondition, the take/Main edge case (Main take cannot be moved), and the returned canonical handle that keeps follow-up edits stable. It stops short of covering failure modes or permission requirements for this mutation.

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?

Four sentences, front-loaded with the operation list, then constraints, then return behavior. No filler and every sentence conveys actionable 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 5-parameter mutation tool with no annotations and no output schema, the description covers the critical decision rules and even the return value. Minor gaps remain around error/edge cases beyond the Main-take exception.

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 the baseline is 3. The description adds the exclusivity rule and the take-specific meaning of `to_root`, but the per-parameter semantics of `parent`/`before`/`after` are already spelled out in the schema's own descriptions.

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 opens with a specific verb and resource and enumerates the three distinct operations (reparent, promote, reorder), making it immediately distinguishable from siblings like create_entity, clone_entity, and remove_entity. An agent can tell what this does 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?

It gives concrete selection rules: exactly one of `parent`, `before`, `after`, or `to_root:true` must be supplied, siblings/parents must share the moved node's kind, and `to_root` behaves differently for takes. What is missing is routing to any alternative tool, though no sibling tool competes for this operation.

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 discloses the core behavior (insert and focus) and explicitly notes the current document is not overwritten, which is a key side effect. It doesn't cover all possible side effects (e.g., undo stack), but given the tool's simplicity, this is adequate.

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 sentences with no filler. The primary action is front-loaded, and the usage context follows immediately. Every word earns its place.

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 simple creation tool with two optional parameters and no output schema, the description fully covers purpose, behavior, and usage. Nothing an agent needs to call it 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 coverage is 100%, with both 'name' and 'make_active' described in the schema. The description only mentions 'by default switch focus' which mirrors the schema's default for make_active, adding no extra semantic value. Baseline 3 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?

The description states a specific action ('Insert a fresh empty BaseDocument'), a clear resource, and the side effect ('switch focus to it'). This distinguishes it from siblings like open_document, list_documents, and set_active_document, making the tool's purpose unambiguous.

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 a concrete use case ('starting a clean scene without overwriting the current one'), which implies when to use the tool. It doesn't explicitly name alternative tools or exclusions, but the context is clear enough for an agent to decide.

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 empty annotations, the description carries the burden. It discloses the core behavior (new document creation) and the make_active parameter's effect on focus. It also mentions the distinction from import_scene's merge behavior. This is adequate, though it doesn't detail error handling or interactions with the current document beyond the implicit new-document creation.

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 sentences with a parenthetical, no fluff. The main purpose is front-loaded, and the key distinction from import_scene is immediately presented. Efficient and well-structured.

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 simple load operation with only two parameters and no output schema, the description covers the purpose, the parameter behavior, and the critical sibling distinction. It doesn't need to discuss return values. Could mention error conditions or current document state, but those are minor gaps for a straightforward 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 100%, so both parameters are documented. The description adds marginal value by restating the effect of make_active and its default, slightly clarifying how to use it. This aligns with baseline 3 for full schema 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 clearly states it loads a Cinema 4D scene file as a new document, a specific verb and resource. It also explicitly differentiates from import_scene, making the purpose unambiguous for an agent.

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 specifically contrasts with import_scene, explaining that this opens a file as its own document rather than merging. This gives clear when-to-use guidance for the most relevant sibling, though it doesn't enumerate all potential alternatives like new_document.

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?

Annotations declare readOnlyHint=true, which the description aligns with. The description adds no additional context such as possible failure modes, timeouts, or what a successful response looks like. Given the simple nature of a ping, the description is acceptable but minimal.

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 with no wasted words. The core action and target are stated immediately.

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 simple connectivity check with no parameters and no output schema, the description is sufficient. It could mention the return value (e.g., success/failure), but this is lightly implied by 'check connectivity' and is not a major gap for such a basic 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?

The tool has zero parameters, and schema coverage is 100% (empty properties). The description correctly adds no parameter information because none exist. This meets the baseline for a parameter-less tool.

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 clearly states a specific verb ('Check') and resource ('connectivity to the Cinema 4D bridge plugin'). It distinguishes from sibling tools by indicating this is a connectivity test rather than a document or scene operation.

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?

No guidance on when to use this tool versus alternatives. There is no mention of prerequisites, typical usage scenarios (e.g., before other commands), or cases where it should be avoided. Usage is only implied.

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 full responsibility for behavioral disclosure—and it excels. It discloses that the active editor view is temporarily switched to Constant Shading (Lines), that the render is built freestanding and never inserted, and that BaseDraw/camera/time/take state is restored in finally. It also states it returns a base64 PNG inline. This is exemplary transparency about side effects and restoration behavior.

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 dense but well-structured. It opens with the core purpose ('Quick agent-friendly verification render'), then details the renderer and state restoration, followed by output format, and finally the view/camera/save_path options. Every sentence adds value, though it is slightly longer than necessary for the amount of detail (e.g., the try/finally detail could be implied). No fluff.

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?

Given the tool's complexity (7 parameters, no required, no output schema, no annotations), the description is remarkably complete. It covers the return format (base64 PNG), the side effects (state restoration), the mutual exclusivity of view/camera, and the optional disk write. An agent has everything needed to invoke it correctly without additional context.

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?

Although schema coverage is 100% (all parameters documented), the description adds meaningful semantic context beyond the schema. It explains that 'view' presets place a temp camera looking at scene bounds and that it is removed in finally, that 'camera' is mutually exclusive with a non-'current' view, and that save_path still returns the base64 PNG inline. This goes beyond the raw schema definitions and enriches agent understanding.

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 clearly states the tool does a 'quick agent-friendly verification render' using the Viewport renderer with Constant Shading (Lines). It explicitly distinguishes itself from a full render (independent of active RenderData, freestanding) and even contrasts with siblings like 'render' by being a lightweight preview. The verb 'render' with the resource 'preview' is precise and the styling detail (sketch-style and fast) further clarifies purpose.

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 establishes clear context: it is for quick verification, not final output, and it is independent of the active RenderData. It explains the view/camera options and the save_path for disk output. However, it does not explicitly state when NOT to use it or name a specific alternative (like 'render' for final renders). The implied usage is strong but lacks explicit exclusions.

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?

Annotations declare destructiveHint=true, and the description adds a genuinely useful trait not in the annotations: the deletion is wrapped in an undo step, so it is reversible. It stops short of describing side effects such as what happens to children/tags of a deleted object or to materials still assigned to objects.

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 with the verb first and zero filler. Nothing can be trimmed without losing the undo-step fact.

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 destructive tool with no output schema, the description covers the core action and reversibility, which is close to sufficient. It omits what the call returns on success and any failure behavior for unresolvable handles or cascade effects on related entities.

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 100% and the handle union is fully described in the schema, so the baseline is 3. 'The resolved entity' adds a small hint that the handle must come from a resolution step rather than being hand-constructed, but no format or example detail is added beyond 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?

The description gives a specific verb+resource ('Delete the resolved entity'), which is unambiguous and clearly distinct from siblings like create_entity, move_entity, and clone_entity. It does not, however, explicitly name any sibling or scope limit (e.g., single entity only, not a batch operation like `batch`).

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 when-to-use guidance and no named alternative. The parenthetical about the undo step hints that the operation is reversible via the `undo` sibling, but the agent must infer that itself; nothing tells it when to prefer this over reset_scene or batch deletion.

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?

Annotations already declare destructiveHint=true, so the deletion semantics are covered. The description adds the non-obvious constraint that the id must be a stable maxon.Id and gives its provenance, but says nothing about irreversible effects, whether connected edges are cleaned up, permission needs, or side effects.

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 sentences, front-loaded with the action and resource, then the id constraint. 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?

Covers id provenance well, but for a destructive mutation tool with no output schema it omits what happens to dependent nodes/edges and error behavior on missing ids. An agent could call it, but not predict consequences.

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 100%, so baseline is 3. The description goes further by defining the exact id format and where it comes from, which the bare schema field 'node_id' does not convey. It does not address the scope/handle/node_space parameters, but those are self-documented.

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 (delete) and resource (node by id in a node-material graph). By naming 'node-material graph' and the sibling functions list_graph_nodes and apply_graph_description, it distinguishes itself from the parallel remove_xpresso_node and remove_entity 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?

Implies use through 'the id must match ... as reported by list_graph_nodes or assigned via $id in apply_graph_description', giving a discovery path, but never states when to prefer this over remove_xpresso_node or other removal tools, nor any preconditions.

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?

Annotations already mark this as destructive (destructiveHint: true). The description adds valuable context beyond that: how identical markers are disambiguated ('error if several markers match'), that `all:true` ignores selectors, and the exact return shape `{removed: N}`. It doesn't mention reversibility or side effects, but destructiveHint covers the main risk.

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 sentences carry full operational meaning with zero filler. The primary action and modes are front-loaded, followed by the disambiguation rules and return value. Every clause earns its place.

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 destructive tool with no output schema, it covers the action, selector rules, error conditions, and return value. A minor gap is that it doesn't explicitly state what happens when no selector or `all` is given, leaving that edge case to the agent's inference. Still, the coverage is strong and sufficient for correct invocation.

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 descriptions are 100% per-property, giving baseline 3. The description goes further by adding the relationship between parameters: exactly one of `index`, `frame`, or `name` for a single target, and `all:true` overriding the selectors. It also clarifies error semantics for ambiguous matches, which is 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?

The description opens with 'Delete one timeline marker, or all of them,' which names a specific verb and resource and explicitly distinguishes the two deletion modes. It is clearly distinct from siblings like create_marker, list_markers, and set_marker, so an agent can select it unambiguously.

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?

Provides clear when-to-use guidance for each parameter path: pass `all:true` to clear everything, or choose exactly one of `index`, `frame`, or `name` for a single target. It also warns that `frame` and `name` error on ambiguity, and points to `list_markers` for getting the `index`, which is practical routing information.

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?

The destructiveHint annotation already flags this as a write, and the description adds the valuable nuance that the deletion is 'wrapped in undo' — i.e., recoverable — which the annotation does not convey. It stops short of explaining failure behavior for invalid paths.

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; the destructive action and its requester path are front-loaded, and the undo note is appended without 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 two-parameter destructive tool with annotations covering safety, no output schema, and full schema coverage, this is nearly complete; the undo note closes the main behavioral gap. Only edge-case behavior is unaddressed.

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 100%, including a documented desc_id format and the polymorphic handle, so the schema carries the load. The description adds only the provenance of desc_id, which is marginal over what the schema already provides — baseline 3.

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 (Delete) and resource (User Data slot) plus the identifying argument (DescID path). By naming list_user_data and add_user_data as the producers of that path, it cleanly distinguishes itself from those 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?

It gives clear workflow context by telling the agent where desc_id comes from (list_user_data or add_user_data), which is a real prerequisite. It does not, however, name an explicit 'when not to use' or contrast with siblings like remove_entity or remove_marker.

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?

Annotations already declare destructiveHint=true, so the safety profile is covered. The description adds genuinely useful behavioral detail beyond that: all incoming/outgoing connections on the node are severed automatically, which sets expectations about side effects. It does not discuss error cases or whether removal is reversible.

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?

Three tight sentences, front-loaded with the operation, followed by the handle requirement and the side effect. Every sentence earns its place with 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-parameter destructive tool with no output schema, the description covers purpose, prerequisite handle acquisition, and cascade behavior. It is nearly complete, though it omits any error/failure behavior if the handle is invalid or the node 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 100%, so the baseline is 3. The description adds meaning by specifying the handle must be a 'gv_node' kind and by pointing to list_xpresso_nodes as the way to obtain the path id, which helps the agent satisfy the anyOf constraint correctly.

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: 'Delete a GvNode from an Xpresso graph.' This is precise enough to distinguish the Xpresso-scoped removal from the generic sibling remove_graph_node, and the agent can identify the operation 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?

It gives clear context by naming the discovery step ('use list_xpresso_nodes to discover its path id'), which tells the agent how to obtain a valid handle before invoking. It does not, however, explicitly address when to prefer this over remove_graph_node or state any exclusions.

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?

Without annotations, the description carries the behavioral disclosure burden and provides important runtime context: calls time out after 180 seconds, heavier renders continue running, and the call returns a timeout. It does not describe success-return details, but the key asynchronous/timeout behavior is 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?

The description is compact and front-loaded: it states the action first, then the relevant workflow, then the timeout caveat. Every sentence adds useful guidance and nothing is redundant with the schema.

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 small tool with one optional parameter, the description covers the main escape-hatch behavior, the dependency on active RenderData settings, and the timeout policy. It does not describe the exact return shape, but for a render call this is a minor gap given the clearly documented tool purpose and behavior.

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?

There is only one parameter, output_path, and the schema already describes it fully as optional, absolute, and defaulting to a temp file. Since schema coverage is 100%, the baseline is 3, and the description adds nothing further about the parameter.

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 clearly states the operation: render the active Cinema 4D document using the currently active render data settings. It specifies a concrete verb, resource, and the settings scope, which helps distinguish a full render from sibling functions like preview_render.

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 explicitly routes the agent to adjust RenderData first via create_render_data or set_params if resolution, renderer, frame range, etc. need changing. It does not explicitly discuss when the sibling preview_render should be used, so it lacks a full when/when-not contrast.

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?

Annotations declare destructiveHint=true, so the destructive nature is known. The description goes well beyond: it specifies exactly what gets removed (objects, materials, non-active render data, non-main takes), the undo buffer flush, the full-document swap without prefix, and the performance rationale. This is substantial behavioral context that annotations alone don't provide. The only minor gap is that it doesn't mention return value or errors, but with destructiveHint true and no output schema that's acceptable.

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?

Three sentences, each dense with information, front-loaded with the core behavior and conditional logic, then a performance note. No fluff.

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?

Given it's a destructive tool with two branches (prefix and no-prefix), the description fully specifies what gets removed, the undo flush, the keep_active_rd default, and why it beats remove_entity. The output schema is absent but not needed for a void-ish operation. 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 100% (both params documented), but the description adds crucial semantics: the prefix param's behavior is explained ('removes only objects / materials / non-active render data / non-main takes whose name starts with the prefix'), and the interaction with keep_active_rd (prefix-mode only, default true) is stated. It explains the conditional behavior of prefix vs no prefix in plain language. Adds clear meaning beyond 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?

Description opens with 'Clear scene state in one RPC' — a specific verb and resource. It then distinguishes two modes (prefix vs full reset) with concrete effects: removing objects/materials/render data/takes matching a prefix plus flushing undo, or swapping the active document for a fresh BaseDocument. Clearly distinct from siblings like remove_entity and undo.

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 states when to use each mode — 'with prefix' for targeted cleanup, 'without prefix' for full reset — and names the alternative, remove_entity, with a concrete comparison: 'Much faster than chained remove_entity calls when cleanup involves animated objects.' Gives the exact context (test cleanup) where this tool is appropriate.

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 are present, so the description carries the full behavioral burden. It clearly states that the tool evaluates and returns transforms, but it does not disclose side effects such as playhead changes or restoration, safety profile, or read-only status, leaving the schema's restore_time parameter to cover some of that ground.

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 sentences with no filler: the first states the core operation and the second gives a focused use case. The structure is front-loaded and every sentence earns its place.

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 and no annotations, the description must carry more return-value and behavioral context. It says transforms are returned, but not the shape of multi-frame results or side effects like playhead restoration, though the rich parameter schema covers inputs adequately.

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 all six parameters are already well documented in the input schema. The description adds no parameter-level meaning beyond what the schema provides, such as format, space, fps, or handle resolution details.

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: evaluate the scene at each requested frame and return the object's transform. The use case implicitly distinguishes it from raw keyframe or transform-setting tools, though no sibling MCP tool is named explicitly.

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