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

With no annotations, the description carries the behavior burden. It discloses the mutation ('Add'), the return type (DescID as a nested list), and a concrete downstream use (path for get_params/set_params). It does not cover duplicate-slot or error behavior, but the core behavioral contract is stated.

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 definition is compact and front-loaded: action/target in the first sentence, return behavior in the second, dtype aliases in the third. The dtype list is slightly redundant with the schema enum, so it is not perfectly lean, but there is 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 an 8-parameter, 3-required write tool with no annotations and no output schema, the description covers purpose, target class, return value, and integration path, while the schema covers parameter details. The main missing pieces are explicit sibling routing and error/duplicate behavior, which are not critical to a first correct call.

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, handle, dtype, min/max/step/value/default, including the vector/color [x,y,z] format. The description mostly restates the dtype enum, so it adds little parameter-level meaning beyond the schema 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?

The description starts with a specific verb ('Add'), a specific object ('new User Data slot'), and scopes the target ('any BaseList2D'), which is enough to distinguish it from sibling list_user_data/remove_user_data even without naming them. The rigging/control-exposure context adds real-world 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?

It gives a clear use-case signal ('common rigging / control-exposure pattern') and explains the returned DescID can feed get_params/set_params, so an agent can infer when it is useful. However, it never explicitly says when to prefer this over list_user_data/remove_user_data, and there are no exclusion or alternative statements.

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 mutation, on-demand graph creation, scene-node type restrictions, and unsupported operations for scene-nodes. It stops short of clarifying whether an existing graph is merged or replaced and what the tool returns on success or failure.

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 front-loaded with the core operation and syntax, and nearly every clause adds value. The inline JSON example and long caveat-laden sentence make it slightly harder to scan than necessary, but it is appropriately sized for the complexity of the tool.

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 tool with no output schema, the description is remarkably complete: it covers input syntax, supported graph types, scope, node_space behavior, and the default create_graph behavior. The main gaps are the lack of any statement about return values/error behavior and the merge-vs-replace semantics on an existing 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?

Although schema coverage is 100%, the description adds meaning well beyond the schema by explaining the special keys in the `description` parameter ($type, $id, '->' wiring), giving a nested example, and clarifying scope/node_space defaults and scene-node asset-id sourcing. This is genuinely useful for an agent constructing a valid call.

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 operation—building or mutating a node graph via maxon.GraphDescription dict syntax—and gives concrete examples of node creation, stable ids, port wiring, and port values. It also names the graph families it applies to (standard/redshift materials and the scene-nodes document graph), which helps distinguish it from Xpresso-related sibling 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?

It provides strong contextual guidance: material graphs vs document scope, where to source scene-node asset ids, and the material-only restriction on queries/labels. However, it never explicitly names a sibling tool as the alternative for other graph types (e.g. apply_xpresso_graph), so some routing decisions are left to inference.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It appropriately says the tool creates nodes, wires connections via GvPort.Connect, and can optionally create a Texpresso tag; the example also implies EventAdd must be called separately. However, it does not disclose whether the call appends to or replaces an existing graph, what happens if the tag already exists, or side effects beyond 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?

The description is front-loaded with the core purpose and sibling distinction, then packs in parameter aliases and an example workflow. It is dense but not bloated; the long alias list is justified because those values are not enumerated in the schema. A slightly more structured layout (e.g., bullets for aliases) could improve scannability, 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?

Given the very rich nested schema, the description does not need to re-explain the node/connect structures. It adds the essential contextual pieces: sibling comparison, operator alias catalog, tag auto-creation, and an end-to-end example. The main omission is return-value behavior and whether the graph is replaced or augmented, but the description is largely complete 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. The description adds real value beyond the schema by listing the accepted short aliases for operator_id, giving a concrete integer example (c4d.ID_OPERATOR_CONST=1001150), and explaining the handle semantics for objects versus existing tags. This makes the parameter surface more usable without repeating schema 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?

The description clearly states a specific purpose: declaratively building an Xpresso GvNodeMaster graph by creating nodes and wiring connections. It also explicitly distinguishes itself from apply_graph_description, naming the sibling tool and the material-vs-Xpresso difference, so an agent can select it correctly even before 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?

It positions the tool as the Xpresso counterpart to apply_graph_description and frames it as a one-call declarative builder, which tells the agent when to prefer this over stepwise graph tools. The example workflow (create Cube -> apply_xpresso_graph -> EventAdd) adds concrete usage context, and the optional tag-creation behavior clarifies when an object handle vs. tag handle 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?

With no annotations, the description must carry the behavioral burden, and it does: it states that a Texture tag is created, that an existing tag can be updated when update_if_exists is true, and that projection aliases avoid raw TEXTURETAG_* ids. It does not detail failure modes or duplicate-tag behavior when update_if_exists is false, but the core mutation and side effects are 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 two sentences: the first identifies the primary action and update behavior, and the second adds value by summarizing projection aliases. No filler or redundant restatement 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 mutating tool with no annotations and no output schema, the description covers the essential behavior, the update path, and the projection vocabulary. It does not mention failure behavior or what the response contains, but these are secondary for such a straightforward assignment action.

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 a score of 3 is the baseline, but the description adds meaningful context beyond the schema: the projection alias list clarifies that the enum values are aliases, and the update_if_exists behavior is linked to the tag-creation workflow. This helps the agent understand parameter intent without opening the full 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 and resource: 'Link a material to an object by creating a Texture tag.' This clearly distinguishes it from material-creation and layer-assignment siblings such as rs_create_material and 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 core use case is clear: assigning a material to an object via a Texture tag. It does not explicitly name alternatives or exclusion conditions, but the context is strong enough that an agent can infer when to invoke it.

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 disclosure burden. It usefully discloses that passing layer:null clears the assignment and that the layer must already exist. However, it does not mention whether a previous layer assignment is overwritten, what error occurs for an invalid target, or what the tool returns on success.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences deliver the primary action, the clearing special case, and the key prerequisite. There is no filler or redundancy; 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 two-parameter tool with a rich schema and no output schema, the description covers the essential operational details: what the tool does, how to clear, and the layer-existence prerequisite. It omits minor behavior like return values and overwrite semantics, but these are not critical for correct invocation given the schema's 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?

Schema description coverage is 100%, so the schema already explains both parameters. The description adds a little context by naming object/tag/material targets and repeating the null-to-clear behavior, but that null behavior is already in the schema. The target parenthetical is also underinclusive relative to the schema's many supported kinds, so no bonus 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 uses a specific verb ('Place') and resource ('named layer'), and clarifies the accepted target types. It is immediately distinguishable from sibling layer/material tools like create_layer, get_object_layer, and assign_material because the action is explicitly 'assign target to a 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 description gives a clear use context: place a target on a named layer. It also provides a direct prerequisite — 'The layer must exist — call create_layer first if needed' — which helps the agent decide on a precondition action. It does not explicitly contrast with alternatives like assign_material, 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?

With no annotations provided, the description fully carries the burden and does so well: it discloses main-thread execution, sequential application, per-op error recording, default undo grouping, active-document binding/restoration, and rejected operation categories. This goes far beyond a minimal 'run multiple ops' statement.

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 dense sentences with no filler; the core action is front-loaded and operational details follow logically. Every sentence earns its place by conveying a distinct behavioral aspect of the tool.

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 combined with the fully documented schema covers execution semantics, error handling, undo behavior, and scoped document handling. The main omission is the shape of the return value, which matters more because there is no output 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 the baseline is 3. The description adds meaningful semantics by explaining the default behavior of undo_group and stop_on_error and the full document_name scoping model. It does not discuss timeout_ms, but the schema already documents that parameter clearly.

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 action ('Run many generic ops in one main-thread RPC') and clearly identifies the resource as a composite operation executor. The batching behavior is distinct from the many individual sibling tools, so an agent can tell this is a container for other registered handlers.

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 ordering, per-op failure continuation, undo grouping, and document_name scoping, giving clear context for when this tool is appropriate. It does not explicitly name alternative tools or say 'use this instead of running individual ops', but the use case is strongly 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 the full burden of behavioral disclosure, but it only says 'Invoke' and names the API. It does not warn that many commands mutate the scene, may block the main thread, may open UI, or may have no meaningful return value. The synchronous behavior is only mentioned in the timeout parameter description, not in the tool description.

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 a single, front-loaded sentence that states the action, the target resource, the mechanism, and the scope of supported commands with useful examples. There is no wasted text.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description and schema together cover the command_id, subid, timeout, and discovery path, which is enough to make a basic call. However, because there are no annotations and no output schema, the description leaves the agent uncertain about side effects, return values, and failure modes for a potentially mutating call.

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 input schema fully documents command_id with examples and discovery guidance, plus subid and timeout_ms. The description adds little beyond saying 'by plugin id', so a baseline score of 3 is appropriate because the schema handles the semantic load.

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 ('Invoke') and names the exact resource ('Cinema 4D command by plugin id') and mechanism ('via c4d.CallCommand()'). It clearly differentiates this generic command invoker from specialized siblings like render or save_document by emphasizing the plugin-id/CallCommand path.

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 built-in commands and registered command plugins, and gives examples like render, save, and make editable. However, it does not explicitly state when to prefer this tool over dedicated siblings such as render or save_document, nor does it state when not to use it.

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 it does well: it explains type-specific cloning behavior, copies VideoPosts and take overrides, describes default object placement, and states the return value. It does not discuss edge cases or potential side effects, but 'duplicate' strongly implies the original remains intact.

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 dense sentences, each contributing distinct information: core operation, supported entity types, placement defaults, and return value. No filler or redundancy; 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 tool supporting many entity types with no output schema, the description covers the key invocation details: supported kinds, parent semantics, type-specific behavior, and return handle. It could go deeper on failure modes or whether object children are cloned, but it is complete enough for an agent to call 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% and the parent parameter already has detailed per-type semantics. The description adds value by explaining the default placement behavior for objects and the option to pass parent to relocate the clone. This goes beyond the schema and helps an agent invoke the tool 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?

The description opens with a specific verb and resource: 'Duplicate an entity,' then enumerates the supported entity types (object, tag, material, shader, render_data, video_post, take) and their implementation paths. This clearly differentiates it from siblings like create_entity and move_entity.

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 clear context for when the tool applies: duplicating an existing entity across multiple supported types. It also clarifies default placement for objects and the ability to override via parent. It does not explicitly name sibling alternatives, but the duplication semantics are unambiguous 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?

With no annotations, the description carries the full disclosure burden and delivers: closing discards unsaved work without a prompt (explicitly contrasted with the GUI), unsaved documents are refused unless force is set, and C4D's one-document minimum means the last close leaves a fresh empty document active. These are exactly the behavioral surprises an agent needs before invoking a destructive close.

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 dense sentences, each earning its place: action/identification, force/discard semantics, and the last-document edge case. No redundancy with the schema and 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 destructive, conditional tool with three parameters and no annotations or output schema, the description covers every decision point: target selection, exclusivity, unsaved-change handling, and the edge case. Only the success-response format goes unmentioned, which is minor for a close operation.

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 the critical exclusivity constraint — 'Pass exactly one of the two' — that the schema's individual property descriptions cannot express, and ties index directly to list_documents output.

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 — 'Close an open document' — and clearly anchors identification to list_documents output. This makes it immediately distinguishable 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?

Gives explicit invocation guidance: pass exactly one of index or name, source the index from list_documents, and use force:true as the escape hatch for unsaved changes. It does not explicitly name an alternative tool (e.g., save_document) as the when-not-to-use path, but the context is otherwise 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?

With no annotations, the description carries the behavioral disclosure burden. It clearly discloses that the tool mutates by creating entities, returns a handle for chaining, and that object handles include `path` for stable re-resolution. It also warns about classical vs. node-material shader behavior, which is important non-obvious 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 every sentence earns its place: scope, return value/chaining, shader caveat, and video_post clarification. Key behavioral constraints are front-loaded before the longer kind-specific notes.

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 and absence of an output schema, the description covers the most important context: what it constructs, what it returns, how to chain follow-up calls, and which sibling to use for node materials. The return handle format for non-object kinds is left somewhat underspecified, but the overall guidance is strong.

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. The description adds meaningful parameter context beyond the schema: it ties `kind` to specific behaviors (classical shader chains vs. node materials, video_post renderer effects) and gives concrete renderer IDs, which helps the agent understand `type_id` and `parent` intent.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: it is a 'unified constructor' for object, tag, material, shader, and video_post. It clearly distinguishes the tool from siblings by naming its scope and unique return behavior (handle with stable `path` for chaining).

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 says when to use it ('Unified constructor... in one call') and gives a concrete alternative: for node-material edits, use `apply_graph_description` instead. It also clarifies kind-specific behavior for `shader` and `video_post`, helping an agent choose correctly.

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?

There are no annotations, so the description carries the full burden. It discloses that the layer is created at the document root, that update_if_exists:true updates the existing layer in place, and that the operation is idempotent. It does not mention what happens if a duplicate name exists without update_if_exists, but the core behavior is transparent.

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 dense sentences with no filler. The main purpose is front-loaded, and each clause adds useful information—creation location, idempotent update behavior, and configuration options.

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 create/update tool with a nested flags object and no output schema or annotations, the description covers the essential decision points: where the layer is created, how idempotency works, and how to configure color/flags. It leaves some details to the schema, but nothing critical blocks 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, but the description adds real meaning beyond the schema by explaining the update_if_exists behavior in detail and showing that color and flags can be passed together or separately. It also gives example flag names, reinforcing what those parameters do.

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 specific verb 'Create' and the resource 'LayerObject at the document's layer root'. It also distinguishes the idempotent update behavior via update_if_exists, making it easy for an agent to understand what this tool does without confusing it with layer-related 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?

The description implies the main use case—creating a new layer or idempotently updating an existing one by name—but it does not explicitly mention when to prefer this tool over alternatives like assign_to_layer or set_layer_flags, nor does it list exclusions. Usage context is clear only by 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 behavioral disclosure burden. It does disclose the update-if-exists behavior and the returned handle, which is helpful. However, it omits side effects, such as the update_if_exists flag condition, make_active effects, default parent handling, or what happens to unspecified settings during an update.

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 that front-load the core action, summarize the key parameter groups, and state the return value. There is no fluff or repetition of schema details.

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 plus the fully documented schema give an agent enough to invoke the tool correctly. The return handle and chaining hint fill the main gap left by the missing output schema, though a note about the update_if_exists condition would make it 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 every parameter. The description adds only a high-level grouping of resolution, renderer, fps, and frame range, which is useful but does not materially extend what the schema already provides.

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 action (create/update), a specific resource (RenderData), and the key attribute groups (resolution, renderer, fps, frame range). It also states the return value, making the tool's purpose unmistakable and distinguishing it from generic create tools like create_entity or create_take.

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 clearly frames the tool as a one-call setup operation and explains that the returned handle is meant for chaining with create_take or set_params. It does not explicitly name alternatives or exclusions, but the intended workflow 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?

With no annotations, the description carries the transparency burden. It does disclose an important non-obvious behavior — new takes are checked by default so they participate in batch renders — and states the return value. However, it does not clarify update semantics, such as whether updating an existing take merges or overwrites camera/render data when the clear flags are not set.

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 every phrase earns its place: sub-operations, default behavior, rationale, return value, and intended use case. No filler or redundant 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 9-parameter mutation tool with no annotations and no output schema, the description covers the core action, default behavior, return value, and the main use case. The schema handles individual parameters, but the description omits details about update-if-exists behavior and error conditions, so it is 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?

All nine parameters are already documented in the schema (100% coverage), so the baseline is 3. The description's `checked:false` mention repeats what the schema already says and adds no new parameter-level meaning.

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 the core operation precisely — 'Create or update a Take' — and enumerates the bundled sub-operations (AddTake + SetCamera + SetRenderData + SetChecked), so the tool's function is unmistakable. It does not explicitly distinguish itself from the similarly named sibling `take_override`, so it falls just short of full sibling differentiation.

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 context by framing the tool as the one-call compound alternative and suggesting a concrete use case: 'building per-shot take stacks programmatically.' It does not name alternatives or state when not to use it, so it lacks the explicit exclusion guidance needed for 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 provided, the description carries the full disclosure burden and handles it well. It reveals the potentially destructive default ('Omitting all frame bounds deletes every key on that track'), the non-obvious matching behavior ('fractional key times are not rounded into the selection'), and the return shape '{removed, track}'. This meaningfully exceeds what the schema alone communicates.

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 dense sentences, each earning its place: purpose, selection semantics, default destructive behavior, and return shape. The core purpose is front-loaded and there is zero filler or repetition of schema content.

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 annotations and no output schema, the description covers the critical ground: all three selection modes, precision behavior, the all-or-nothing default, and the response format. The 'handle' target parameter is left to the schema, but the schema documents it thoroughly. The only notable gap is the absence of any mention of reversibility/undo, though an undo sibling exists in the toolset.

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%, setting a baseline of 3. The description adds value beyond the schema by explaining the interplay between frame/start_frame/end_frame — exact match, inclusive range, or full-track deletion — which the individual parameter descriptions ('Single frame to remove', 'Inclusive lower bound') do not convey. It also frames the path vs param_id/component dichotomy up front.

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 pair — 'Remove keys' — and immediately clarifies the two selection mechanisms (full path vs legacy param_id/component). This cleanly distinguishes the tool from siblings like delete_track (removes whole tracks) and set_keyframe (adds keys), though it does so implicitly rather than by naming an alternative.

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

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives solid parameter-level usage guidance: integer frame for exact-time, start_frame/end_frame for inclusive range, and omitting all bounds to delete every key. However, it never addresses when to choose this tool over siblings such as delete_track or edit_fcurve_keys, so the tool-vs-alternative selection context is left 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the return value but does not disclose that the operation is destructive and irreversible, whether keyframes are removed along with the track, or any permission/undo implications. 'Remove' only implies mutation without explaining consequences.

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 states the action, identification modes, and return value with no filler. Information is front-loaded and every word contributes.

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 purpose and return shape, and the schema handles parameter details. However, for a destructive mutation tool with no annotations and no output schema, it would benefit from stating that deletion is permanent and affects the associated track data.

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 documentation covers all parameters at 100%, so the baseline is 3. The description does add a small grouping distinction between 'full path' and 'legacy param_id/component', but the individual schema descriptions already convey exclusivity and meaning for each 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 action ('Remove an entire CTrack') and the resource, and differentiates the scope from editing individual keyframes. It does not explicitly name sibling tools like delete_keyframe, but the whole-track wording makes the distinction apparent.

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 identify a track (full path or legacy param_id/component) but provides no guidance on when to use this tool instead of alternatives like delete_keyframe or remove_entity. There is no explicit when-to-use or when-not-to-use context.

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 disclosure burden. It clearly signals a read-only discovery operation through 'Dump', 'current value', and 'before reading/writing'. It also discloses notable behaviors in the handle explanation, such as plugin_options resolving to the plugin's settings BaseList2D and GvNode inheriting BaseList2D so describe works on it. It does not explicitly state side-effect freedom or error behavior, but the read-only nature is strongly implied.

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 main description is two concise sentences that front-load the purpose and usage with no filler. The lengthy handle explanation lives in the schema where the complexity justifies it, rather than bloating the top-level description.

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 discovery/read tool with one parameter, the description is complete: it states the output fields even without an output schema, and the handle schema exhaustively covers all supported entity shapes. No critical calling information is missing for an agent to invoke 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?

Even though schema coverage is 100%, the handle description adds substantial value beyond the raw schema: alias forms for plugin_id like 'abc'/'fbx', default plugin_type behavior, GvNode path-id discovery via list_xpresso_nodes, and the advice to prefer path over name. This materially improves correct parameter construction.

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 ('Dump'), a specific resource ('description parameters of a C4D entity'), and explicitly enumerates the returned fields (id, name, cycle enum, current value). The phrase 'discover parameter IDs before reading/writing' separates this from value-reading/writing siblings like get_params and set_params.

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 clear situational guidance: use this tool to discover parameter IDs before reading or writing. The handle schema adds valuable context such as 'describe+set_params it to configure exporter options' and the GvNode stable path ID workflow. However, it names no explicit alternatives or when-not-to-use conditions, leaving some inference about where get_params/set_params fit.

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

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

With no annotations, the description carries the full burden and does so thoroughly: it discloses recursive JSON output, per-node fields, Xbitmap-to-file promotion, heuristic file_candidates, and linked_shaders expansion. It stops short of explicitly stating that the operation is read-only with no side effects, but the detailed behavior description strongly implies it.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Every sentence earns its place: primary function, critical scope limitation, output transformations, and discovery guidance. It is dense but well-ordered and contains 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 tool with two well-documented parameters and no output schema, the description supplies the essential output structure and usage context. It tells the agent when to use the tool, what it returns, how to handle classical vs node materials, and how to find shader handles.

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 handle and max_depth fully. The description adds no parameter-specific semantics beyond what the schema provides, leaving it at the baseline of 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?

The description states a specific verb ('recursively dump') and resource ('a shader resolved from a handle into JSON'), and immediately distinguishes itself from node-material tools. It also enumerates exactly what data is captured, making the tool's purpose unmistakable even among many 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?

The description explicitly says classical materials only and directs the agent to use list_graph_nodes / apply_graph_description for node materials. It also recommends pairing with list_entities kind=shader, giving clear when-to-use and alternative 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?

With no annotations provided, the description carries the full burden, and it delivers substantial behavioral detail: left/right are signed offsets, manual takeover splits handles and disables several tangent options, locks are respected, the batch is preflighted, and updates are undo-grouped. This is far beyond what the schema alone reveals.

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 every clause earns its place by adding a constraint, a behavioral caveat, or an exclusion. The main action is front-loaded, and there is no filler or repetition of schema content.

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 mutating tool with no annotations and no output schema, the description covers prerequiaites, concurrency, batch semantics, undo grouping, and exclusions. It tells the agent what to read first, what behavior to expect, and what the tool will not do, making it sufficiently complete for safe 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 86%, so the baseline is already 3. The description adds real value beyond the schema by clarifying non-obvious semantics: left/right are signed offsets rather than absolute positions, manual mode disables automatic/clamp/auto-weight/overshoot/tangent-lock, and key_index refers to a fresh get_fcurve snapshot. This elevates it to a 4.

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 action and target: 'Edit existing REAL keys' and enumerates what can be edited (values, interpolation modes, tangents). It further distinguishes the tool from siblings through explicit exclusions: 'Does not create keys or edit coupled XYZ/time tracks.'

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 preconditions and concurrency guidance: 'Read get_fcurve first' and 'avoid simultaneous scene edits.' It also clarifies what the tool does not do, but it does not explicitly name an alternative tool or provide a when-not-to-use branch, 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?

With no annotations, the description must carry the behavioral disclosure burden. 'Report' implies a read-only, non-mutating operation and the output categories are listed, but the description does not state whether a live C4D connection is required, what 'security posture' covers, or how the output is structured. There is no annotation contradiction.

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 sentence that front-loads the verb and output categories with no filler. Every word earns its place and the structure is immediately scannable.

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-argument report tool, the description gives the essential result categories, but because there is no output schema it should say more about the return shape. The large sibling list, especially rs_get_capabilities, also makes some usage differentiation important. Adequate but incomplete.

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 input schema has zero parameters, so there are no parameter semantics to clarify; the baseline for 0-param tools is 4. The description appropriately focuses on the tool's output rather than inputs.

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 the verb 'Report' and identifies a concrete resource: the Cinema 4D runtime, security posture, and available capabilities. This is more specific than the title and helps distinguish it from the Redshift-focused rs_get_capabilities sibling, though it does not explicitly name alternatives or clarify what 'capabilities' includes.

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 about when to call this tool versus siblings such as rs_get_capabilities, describe, ping, or get_document_state. An agent is left to infer the appropriate context, and there is no mention of prerequisites, exclusions, or precedence.

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 must carry the weight of behavioral disclosure. It communicates that the tool dumps a raw BaseContainer including hidden keys and supports filtering by key range, implying a read-only introspection operation. However, it does not explicitly state that it makes no modifications, describe the output shape, or mention error behavior for invalid handles—gaps that matter given the absence of annotation metadata.

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 no filler. The core action is front-loaded, the distinguishing detail (hidden keys not in `describe`) follows immediately, and the filtering capability is stated economically. Every sentence contributes.

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 handle schema is complex and well-documented in the input schema, but the tool itself has no output schema and no annotations. The description covers the main purpose and filtering but omits expected output format, potential size of the dump, and explicit guidance on when to prefer it over related tools like `dump_shader` or `get_params`. For a tool with this complexity and no annotations, more contextual guidance would be valuable.

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. The description adds meaning beyond the schema by linking `id_from`/`id_to` to the practical action of narrowing output and giving a concrete example of hidden keys. This helps an agent understand the value and purpose of the optional key-range 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?

States a specific verb and resource: 'Dump the raw BaseContainer of a C4D entity.' It immediately differentiates from related tools by noting it includes hidden keys not shown in `describe`, with a concrete example (Octane AOV shader slots at 3740/3741). This unambiguously identifies the tool's distinctive 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 implies when to use this tool by contrasting with `describe` and suggesting key-range filtering to narrow output. It does not explicitly name alternatives or state when *not* to use it, but the context is clear enough for an agent to choose it for raw, complete container inspection.

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

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

With no annotations provided, the description carries the transparency burden. It discloses read-only intent via 'one-shot reader' and lists the data it returns, which is strong for a state getter. It does not mention edge cases like an unopened document or failure behavior, but the core behavioral profile is clear.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single dense sentence that front-loads the core purpose ('one-shot reader') and then lists the relevant fields, followed by one short sentence linking to `set_document`. Every phrase earns its place and there is no filler or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Since there is no output schema, the description compensates by listing the returned fields and their domain. It does not specify exact types or error behavior, but for a zero-parameter state snapshot the essential information an agent needs to choose and invoke the tool 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?

The tool accepts zero parameters and the schema has 100% coverage with an empty properties object, so there is no parameter documentation burden. The baseline of 4 applies because the description does not need to explain parameter meanings that do not exist.

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 identifies a read operation on the active document and enumerates the exact fields returned: fps, frame ranges, current frame, document name/path, and camera/take/render handles. It also distinguishes itself from `set_document` as the writer counterpart, making its purpose unambiguous among the large 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?

The description provides clear usage context by positioning this as the reader paired with `set_document` for the writer side, implying use when you need a current document snapshot rather than a mutation. It does not explicitly enumerate when not to use it versus other getter-like siblings such as `get_params` or `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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the operation is non-mutating ('Does not create a track/curve or change document time'), adds a hard limit ('At most 1000 keys'), notes the snapshot semantics ('stable key indices for this snapshot'), and clarifies what it is not. This is strong coverage, though it could also mention error behavior when the track does not exist.

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 tight and dense: the first sentence states the core capability and data returned, the second adds the sampling option and the 1000-key limit, and the third clarifies side effects and exclusions. No sentence is redundant, and the most important scoping 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 tool has 7 parameters, no output schema, and no annotations, so the description must communicate both behavior and return content. It lists the returned data categories, the optional sampling behavior, the key limit, and side-effect guarantees. It is not fully complete because it does not describe response format, ordering, or failure modes, but it covers the essential calling context well.

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 every parameter, including exclusions between path/param_id/component and the semantics of sample_frames. The description adds the optional sampling concept and the key limit, but does not substantially expand parameter meaning beyond what the schema provides. 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 uses a specific verb ('Read') and resource ('existing REAL F-Curve'), and enumerates exactly what is returned: key indices, frame times, values, interpolation, tangent offsets, and extrapolation. It also distances itself from other readers ('Not a scene/constraint evaluation or character-animation reader'), making its purpose 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?

The description makes clear this is for reading existing real F-curves only and explicitly states it does not create tracks or change document time. It also excludes scene/constraint evaluation and character-animation reading. It does not name sibling alternatives like get_keyframes or edit_fcurve_keys directly, but the exclusions give enough contextual 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 present, so the description carries the burden. It clearly indicates a read/report operation with 'Report' and 'confirm', and it enumerates the returned information. It doesn't discuss error behavior or permissions, but for a read-only inspection tool this is a reasonable and mostly complete disclosure.

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 waste: the first states what is reported, the second states when to call it. The key information 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?

Given no output schema and no annotations, the description provides the essential return categories (node spaces, active node space, alias table) and frames the tool as a preflight check for apply_graph_description. It doesn't spell out the exact output structure or all handle variants, but for a single-parameter read-only tool the high-level summary is 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?

The schema already provides a 'Material handle' description, and the tool description reinforces that this operates on materials, so the intended parameter is inferable. However, the schema actually permits many handle kinds beyond material, and the description doesn't explicitly restrict to the material variant or explain how to construct it, leaving some ambiguity despite 100% 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 uses a specific verb ('Report') and names the exact subject: which node spaces a material exposes a graph in, which one is active, and the alias table. This clearly differentiates it from sibling tools like list_graph_nodes or apply_graph_description, which operate on nodes rather than report node-space availability.

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 says to use this tool before apply_graph_description to confirm the right node_space is addressable, giving a concrete precondition and sequential context. It doesn't name alternative tools or exclusions, but it provides clear when-to-use 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 provided, the description carries the full burden of behavioral disclosure. It states that the tool reads keys, returns a specific data shape, preserves fractional frame positions, and clips inclusively without rounding subframes. This is meaningful behavioral detail, though it does not mention edge cases such as empty results or invalid handles.

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 front-load the core action and resource, then provide return format, precision behavior, and optional bounds semantics. Every sentence contributes useful information with no filler or repetition of schema details.

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?

Despite having no output schema and no annotations, the description provides the return type and key edge-case behavior, while the fully documented input schema covers all parameters. The addressing modes and clipping semantics are explained well enough for an agent to invoke the tool correctly in most cases.

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 all 7 parameters, so the baseline is 3. The description adds value by explaining the relationship between the path and the legacy param_id/component addressing modes, and by clarifying the inclusive clipping semantics of start_frame/end_frame. This goes beyond the schema's simple parameter 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: 'Read keys' using either a full path from list_tracks or a legacy param_id/component. It also states the exact return shape [{frame, value, interp}] and clarifies that fractional frame positions are preserved, which distinguishes this from related keyframe tools like set_keyframe, delete_keyframe, and get_fcurve.

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 clear context on how to invoke the tool: use a full path obtained from list_tracks, or use the legacy param_id/component alternative. It also explains the meaning of optional start_frame/end_frame bounds. It does not explicitly name alternatives or exclusions, but the read-only purpose is sufficiently clear from the wording.

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 present, the description carries the full transparency burden and discloses meaningful behavior: the editable-object requirement, the C4D triangle storage quirk (c==d), and the default 50,000 count cap to protect JSON payload size. It also describes the return representation for triangles and quads.

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 dense sentences cover purpose, prerequisite, output encoding, and limits with no filler. The most important constraint, editable objects and required conversion, appears early.

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 no output schema and no annotations, the description covers the key behaviors: readable object types, conversion prerequisite, geometry encoding, and output caps. It stops short of specifying the exact response structure or what happens when a cap is exceeded, but it is sufficient for an agent 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 coverage is 100%, so the schema already handles parameter definitions. The description adds value by explaining the purpose of the max_points/max_polys caps, how to override them, and reinforces the editable constraint on the handle 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 starts with a specific verb, 'Read', and a specific resource, 'points and polygons (or spline segments)', scoped to editable PointObject / PolygonObject / SplineObject. It clearly identifies what this tool returns and differentiates it from sibling writers like set_mesh and generic get_params.

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 an explicit prerequisite: primitives must be converted via modeling_command make_editable, so an agent knows not to call get_mesh directly on a Cube or Sphere. It does not name an alternative geometry-reading tool, but the conversion routing is enough to establish when the tool applies.

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

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

With no annotations provided, the description carries the burden of behavioral disclosure. It does disclose a key behavior: it returns null if the layer is unassigned. It does not explicitly state that the operation is read-only, nor does it describe error behavior or response format, but these are less critical for a simple getter.

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 a single, focused sentence that front-loads the operation and includes the key null-if-unassigned behavior. There is no filler or redundant content.

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 getter, the description is mostly sufficient, but it omits the full range of supported target kinds and does not describe the format of the returned layer value. Since there is no output schema and no annotations, these gaps leave some ambiguity.

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 schema's target definition is rich enough to document accepted entity forms. The description adds only a partial, somewhat misleading list of entity types, so it does not meaningfully improve on 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 clearly states the tool returns the layer currently assigned to a target entity, which distinguishes it from layer mutation or listing tools. However, it only mentions object/tag/material while the schema supports additional entity kinds like render_data, take, video_post, shader, gv_node, and plugin_options, so the scope statement is incomplete.

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 the tool should be used when you need to query the current layer assignment of an entity, which is useful context. It does not explicitly name alternatives or state when not to use it, so usage guidance is inferred 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?

With no annotations, the description carries the full behavioral burden. It explicitly states the operation is a read, specifies the exact return shape `{values: [{path, value}]}`, preserves request order, and explains dtype inference and override syntax. This is highly transparent for a read-only 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?

Four dense sentences, each earning its place: purpose, id grammar, explicit dtype syntax, return contract and discovery hint. No filler or repetition of schema details.

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 provides the return contract even though no output schema exists, explains the parameter path grammar thoroughly, and points to `describe` for id discovery. Combined with the detailed handle schema, an agent has enough to select and invoke 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?

Although schema coverage is 100%, the description adds critical semantics beyond the schema: valid id forms, chained DescIDs, 'x'/'y'/'z' vector sub-components, and explicit dtype tuples. This is essential for constructing correct `ids` payloads and is not inferable from the raw 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?

The description opens with a specific verb and resource: 'Read parameter values on a C4D entity'. It clearly distinguishes this as a read operation from siblings like set_params, and 'Discover ids via describe' positions it relative to the discovery tool.

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 read context is clear, and it explicitly directs the agent to `describe` when ids need to be discovered. However, it does not explicitly state when to avoid this tool or prefer alternatives like set_params, so it lacks explicit 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?

With no annotations provided, the description carries the full burden of disclosing behavior. It clearly indicates this is a non-mutating read operation ('Read') and specifies the kinds of data returned (active object, selected objects, tag/material). It also mentions the crucial behavior of returning 'canonical handles' suitable for piping to other tools. It does not detail error cases or empty-selection handling, but the core behavioral traits are transparent.

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: the first states the core function, the second explains the primary use case, and the third describes the output format and integration. There is no fluff or repetition; each sentence adds distinct value. 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?

Given there is no output schema and no annotations, the description adequately explains the main return contents (active object, all selected objects, active tag/material) and their nature (canonical handles). It does not specify the exact response structure or empty-selection behavior, but for a simple zero-parameter getter, this is reasonably complete for an agent to invoke and interpret the result.

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 input schema has zero parameters, so the schema itself is complete by definition. The description does not need to explain parameters. The baseline for 0 parameters is 4, and the description does not introduce any conflicting or missing parameter information.

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 ('Read') and a precise resource ('the active document's current selection') with enumerated components: active object, all selected objects, and active tag/material. This clearly distinguishes it from sibling tools like set_selection, which mutates selection, and is far from tautological.

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 this tool is useful: 'reacting to the user's current focus without asking them to re-pick entities.' It also provides a workflow hint by noting that returned canonical handles can be piped into describe or set_params. It does not explicitly list exclusions or alternative tools, but the provided context is clear enough for an agent to select it appropriately.

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 disclosure burden. It explains that the tool mutates the active document by merging, returns newly-imported top-level objects, and can optionally reparent and rename. However, it does not mention side effects such as name collisions, whether the operation changes the active document beyond adding objects, or behavior on merge failure.

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. The first sentence names the core operation and formats; the second covers return value and optional behaviors. Every sentence provides useful signal with no redundancy.

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 there is no output schema, the description usefully states that the tool returns newly-imported top-level objects for chaining. It also covers file formats and optional parent/rename behavior. It is slightly incomplete regarding prerequisites and side effects, but sufficient for an agent to understand the tool's role and 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 description coverage is 100%, so a baseline of 3 applies. The description adds meaningful semantics for parent and rename, clarifying that imported objects are reparented and the first root is renamed. It also explains the return value in relation to the filter. Path and filter remain schema-described, which is acceptable given full coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: merge an external file into the active document via MergeDocument. It also clarifies the return value and optional behaviors, making it clearly distinguishable from sibling tools like open_document or reset_scene.

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: use this when importing/merging an external scene file into the active document. It also mentions chainability with set_params / create_entity / create_take, which helps the agent understand the workflow. It does not explicitly name alternatives or exclusion conditions, but the intent 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?

With no annotations provided, the description carries the behavioral disclosure burden. It communicates that this is a read-only enumeration and details the entry fields: index, name, path, and active status. It also notes that the index is the handle accepted by set_active_document, which is useful behavioral 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 sentences with no filler. The first sentence states the core purpose; the second defines the output; the third points to the relevant alternative. Every sentence earns its place and the purpose 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?

Although there is no output schema, the description fully enumerates what each entry contains. It also places the tool in the larger workflow by connecting the returned index to set_active_document and contrasting with get_document_state. Nothing critical is missing for a zero-parameter read-only list 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, so the description needs to explain no inputs, and it does so implicitly by focusing entirely on the output. The schema coverage is effectively complete, and there is no parameter meaning missing.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'Enumerate the documents currently open in Cinema 4D.' It clearly distinguishes itself from related siblings like get_document_state and set_active_document by identifying what it lists and how the index is used.

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 explains when to use this tool instead of get_document_state: get_document_state only reports the active document, while list_documents reveals the others before switching. This is direct, actionable 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 provided, the description carries the full burden, and it delivers: it discloses the return format, kind-specific fields (is_active for take/material/render_data), the inline data-reading behavior of include_tags/include_params, and the shader-chain vs node-graph behavioral caveat. It stops short of explicitly stating read-only semantics and any result limits, but the return-shape and per-kind behavior disclosure goes well beyond the bare minimum.

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, roughly 85 words, with zero filler. The core purpose and return shape are front-loaded, followed by the object-kind capabilities, then the usage ordering guidance, then the shader caveat. The example and the list_graph_nodes pointer each earn their place by preventing a likely mis-selection.

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?

This is an 11-parameter, kind-dependent tool with no output schema and no annotations, so the description has a heavy burden. It covers the return format, the most confusing behavioral trap (shader vs node-material), and the tool's role in the discovery workflow. The main gap is that the return-value disclosure is partial — fields are enumerated for only some kinds — but 100% schema coverage on parameters and the explicit shader caveat keep this complete enough 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 per-parameter documentation already exists, establishing a baseline of 3. The description adds genuine value beyond that by showing how parameters compose in a real query: 'all cubes with a Ttexture tag and their position in one call' demonstrates the combined use of type_ids, tag_types, and include_params. This composition insight is absent from the schema's individual parameter 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 states a specific verb and resource ('Enumerate scene entities of a given kind') and immediately describes the return shape ('compact summaries (name, type_id, type_name, plus kind-specific fields...)'). It differentiates from siblings by name-dropping the closest alternative (list_graph_nodes) and clarifying that shader enumeration covers classical chains only, so an agent can distinguish this from list_graph_nodes and list_xpresso_nodes 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 description gives explicit sequencing guidance: 'Use this first to find what exists before describe/set_params.' It also names concrete alternatives with selection conditions — 'without falling back to exec_python' and 'for node-material graphs use list_graph_nodes.' This is exactly the when/alternative routing the dimension asks for, with nothing left to inference.

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

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

With no annotations provided, the description carries the behavioral disclosure burden. It discloses that results are filtered to templates actually addable in the scene-nodes space and that supported:false is returned when the maxon framework is absent. This adds meaningful behavior beyond the name and schema. It doesn't describe the full response shape, but the read-only enumeration nature is clear.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, each contributing distinct value: what the tool returns, how the IDs are used, and how the scene-nodes case differs from list_graph_nodes. The main purpose is front-loaded and the examples make the distinction concrete without bloat.

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 one optional parameter, no annotations, and no output schema, the description covers the core semantics: what is enumerated, how node_space affects results, and the supported:false edge case. It does not explicitly state the output structure (e.g., array of strings vs. object with supported flag), but enough is conveyed for an agent to invoke 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?

The schema already documents node_space aliases and the default value well, so the baseline is 3. The description adds extra meaning by linking node_space behavior to the scene-nodes (neutron) case and clarifying how the results relate to apply_graph_description and list_graph_nodes.

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: 'Enumerate registered node-template asset ids for a node space.' It also distinguishes this from the sibling list_graph_nodes by explaining that these IDs differ from the net.maxon.corenode:* IDs reported for existing nodes, so an agent can tell the tools apart.

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 states the primary use case: these IDs are what you pass to apply_graph_description as $type. It also contrasts the scene-nodes filtering behavior with list_graph_nodes, giving useful selection context, though it stops short of an explicit 'use this instead of X when...' formulation.

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 transparency burden. It discloses a list-like behavior, the flat-list result shape, and the `supported:false` failure condition when the maxon framework is unavailable or no graph exists. It does not detail the node object structure or other error modes, but for a list operation this is substantive.

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 short sentences: the core purpose, the two targeting modes, and the key failure signal. It 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?

For a simple list tool with no output schema, the description covers the invocation modes and the main unsupported case. It could be more explicit about the shape of the returned node items, but it is sufficient for an agent to select and 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 coverage is 100% and the schema already explains `scope`, `handle`, and `node_space` defaults/aliases. The description repeats the handle-vs-scope relationship but does not add significant parameter meaning beyond the schema, so it stays at the 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?

The description states a clear action ('Walk a node graph and return a flat list of nodes') and specifies two target scopes: a material handle or the active document's scene-nodes graph. It does not explicitly distinguish this from sibling tools like list_graph_node_assets or list_xpresso_nodes, but its function is concrete and 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?

It gives actionable context on when to use each target: use `handle` for node-based materials and `scope:'document'` for the active scene-nodes graph. It doesn't mention exclusions or alternative sibling tools, so it stops short of a full when-not-to-use comparison.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly states that the tool enumerates all LayerObjects and describes the per-entry return contents: name, optional color, and flag dict. It stops short of explicitly stating that it has no side effects or how it behaves with no active document, but the term 'Enumerate' strongly implies a read-only 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 a single, well-structured sentence. It front-loads the primary purpose and follows with the relevant return details. Every phrase contributes information, and there is no filler or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter list tool with no output schema, the description is complete: it names the resource scope, the enumeration behavior, and the exact fields returned per layer. An agent has enough information to invoke the tool and interpret its result without further clarification.

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 input schema is empty with zero parameters, so the baseline is 4. No parameter-level description is needed because there is nothing for the agent to populate or disambiguate.

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') with a clear resource ('every LayerObject') and scope ('in the active document'). It clearly differentiates this listing tool from the layer-related siblings like create_layer, assign_to_layer, and set_layer_flags, since they are all about mutation or assignment rather than enumeration.

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 intended usage is implied: if an agent needs to inspect all layers in the active document, this is the tool. However, there is no explicit guidance about when not to use it or which alternative to choose, such as get_object_layer for a single layer or set_layer_flags for modifying flags.

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

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

With no annotations provided, the description carries the full burden. It transparently discloses a non-obvious side effect: 'The bridge forces a scene pass so the MoData array is populated before sampling.' It also states the exact failure modes and the supported/unsupported return flag. This is more than most tool descriptions provide, though it doesn't mention performance cost or mutation risk (there is no 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?

Three sentences, each earning its place: purpose, behavioral note, and return format/failure modes. The key verb and resource appear in the first sentence, and the return shape is compactly specified inline. No redundancy 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?

The description covers purpose, behavior, return shape, and failure conditions. With no output schema, the inline return shape `{count, returned, clones: [{index, pos, matrix?}]}` is essential and present. It doesn't explain what 'pos' contains or the matrix format, but those are minor given the tool's narrow scope and the parameter defaults already in 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 the schema documents all three parameters (handle, max_count, include_matrix). The description adds minimal parameter-level detail, but it does clarify that max_count defaults to 2048 and that include_matrix controls the optional matrix field, which is mildly helpful. Baseline 3 is appropriate given full schema coverage and no required extra semantics.

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 ('Read') and resource ('per-clone transforms from a MoGraph generator'), explicitly names supported generators (Cloner / Matrix / Tracer), and is distinguishable from sibling tools like sample_transform or get_mesh. The return format is also stated, which further clarifies what the 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 states the primary use case (reading per-clone transforms) and gives a conditional fallback ('supported:false when the build lacks c4d.modules.mograph or when the handle isn't a MoGraph generator'). It does not explicitly name alternative sibling tools or when-not-to-use scenarios, but the context is clear enough for an agent to decide when this tool applies.

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 transparency burden and does a solid job by explaining the output entry shape (plugin parent folder and plugin_file basename) and the regex filtering behavior. It doesn't explicitly state that enumeration is side-effect-free or describe error behavior, but the enumerator framing makes the behavior predictable.

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 focused sentences with no wasted words. The lead sentence states the tool's purpose, and each subsequent sentence adds a distinct functional detail about input, output, and filtering.

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 enumerator with three optional parameters and no output schema, the description is sufficiently complete: it covers input modes, output entry fields, and filter behavior. Minor gaps such as result ordering and behavior for unknown plugin_type are unlikely to block 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. The description adds meaningful value by clarifying plugin_pattern semantics (matched against folder/binary and useful when the command display name lacks the plugin brand) and by explaining the plugin/plugin_file output attribution.

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 identifies this as a generalized C4D plugin enumerator covering any plugin type, with concrete examples such as material, shader, video_post, and command. This distinguishes it from sibling list_* tools that target documents, layers, tracks, or graph nodes.

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 clear context: pass plugin_type to enumerate plugins, and optionally narrow results with name_pattern and plugin_pattern. It doesn't explicitly name alternatives or exclusions, but no sibling tool appears to be a direct plugin-listing alternative, so the usage context is sufficiently 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?

With no annotations, the description carries the transparency burden. It discloses non-obvious behavior such as vector channels producing separate entries per component and describes the path encoding format. It does not explicitly state that the operation is read-only, but 'enumerate' and the output-focused wording strongly imply a non-mutating 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 compact and front-loaded: first the action, then the returned fields, then the vector-channel caveat and downstream usage. Every sentence earns its place and there is no filler or redundant 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?

There is no output schema, so the description appropriately compensates by specifying each entry field, the full-path structure, and the vector-channel behavior. It also explains how the returned paths are consumed by sibling keyframe and track tools, which is enough context for a simple one-parameter enumeration 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 only parameter, handle, is already documented in the schema as 'Entity whose animation tracks to enumerate,' and the schema coverage is 100%. The description adds no additional input semantics beyond the schema, so the baseline score of 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 opens with the specific verb-resource pair 'Enumerate CTracks' and then lists exactly what each entry contains: name, full path, legacy param_id/component, dtype, and key_count. This makes it clearly distinct from track-editing siblings like set_keyframe, get_keyframes, and delete_track.

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 useful workflow context by explaining that the returned path is meant to be passed with the entity handle to get/set/delete keyframes or delete_track. This clearly positions list_tracks as the discovery step before track/keyframe operations, though it does not explicitly state when not to use it or name a direct alternative.

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 burden of behavioral disclosure. It discloses the return record fields and the downstream use of desc_id, which is meaningful. However, it does not explicitly state that this is a read-only, non-destructive operation or describe any error/edge-case behavior, leaving the safety profile implicit.

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 tight sentences with no filler. The primary action is front-loaded, the return shape is specified in a compact inline object, and the follow-up instruction about desc_id earns its place by connecting this tool to its siblings.

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 correctly takes responsibility for explaining the return values, which it does by listing the entry fields. It also explains how the output should be consumed. It could go further by noting the absence of side effects or behavior on targets with no User Data, but for a simple listing tool the provided context is largely sufficient.

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 for the single handle parameter is 100%, and the schema already describes it as 'Target to inspect.' The prose description adds no new parameter-level semantics beyond restating the target concept, so the baseline score of 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 opens with a specific verb ('Enumerate') and a precise resource ('User Data slots on a target'), and immediately states the shape of each returned entry. This cleanly separates it from sibling tools like add_user_data or remove_user_data without needing to open 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?

Usage context is implied: you call this to inspect User Data slots on a target. It also tells the agent how to use the returned desc_id with remove_user_data, get_params, and set_params. However, it does not explicitly state when to prefer this over get_params or when not to use it, so the guidance is useful but incomplete.

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

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

With no annotations provided, the description carries the full behavioral disclosure burden. It discloses that the operation walks a tag, returns a flat list, provides stable dotted-index path ids, includes port summaries, and handles two input kinds with a defined fallback for object handles. It stops short of describing error cases or output ordering, but for a read-only listing tool the behavior is well specified.

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 earning its place: the first states the core action, the second defines the output's key field and stable path semantics, and the third covers both input variants and downstream usage. The most critical scoping information is front-loaded, and there is zero filler or repetition of schema details.

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 there is no output schema and no annotations, the description adequately explains what is returned (flat list, dotted-index id, port summaries) and how to use the output. It also handles the input flexibility. The main gaps are lack of detail on what exactly 'port summaries' includes and no mention of edge cases (e.g., missing tag or object without a Texpresso tag), but the essential calling contract is 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?

Although the schema documents the 'handle' parameter at 100% coverage, the description adds critical meaning: it clarifies that both tag handles and object handles are accepted, defines exactly what an object handle does (uses that object's first Texpresso tag), and explains the id format plus downstream consumption via `{kind:'gv_node', tag, id}`. This transforms a generic union type into an actionable parameter contract.

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: 'Walk an Xpresso ... tag and return a flat list of its GvNodes.' It names the domain (Xpresso), the aliases (Texpresso / GvNodeMaster), and the exact output (GvNodes), which clearly separates it from generic graph tools like list_graph_nodes.

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 clearly says the tool accepts either a tag handle or an object handle and explains the object-handle behavior ('uses that object's first Texpresso tag'). It also tells the agent how to use the returned ids from downstream Xpresso tools. However, it does not explicitly name when not to use this tool versus a sibling like list_graph_nodes, leaving some inference to the agent.

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 substantial work: it names the underlying API and discloses the key return distinction — new-geometry commands (Current State to Object, Connect/Join, Split, Explode Segments) return handles to inserted results, while in-place commands (Make Editable, Subdivide, Triangulate) return the mutated targets. It stops short of covering error conditions, destructiveness, or potential dialog behavior, but the return semantics are the critical unknown for an agent calling this 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?

Two information-dense sentences front-load the operation and return behavior before a functional alias list. There is no filler; the list length is inherent to supporting 16 command aliases.

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 return-value disclosure partially compensates for the missing output schema and the highly nested targets schema. Gaps remain: no guidance on which aliases support which mode values, no error behavior for invalid command/target combinations, and no indication of whether operations are destructive or undoable — notable for a mutation tool with zero annotations.

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; the description is genuinely additive by expanding the command parameter into its full alias set and hinting at params usage with the 'subdivision level' example. This enriches what the schema's terse one-line descriptions provide.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'Run a Cinema 4D modeling operation via c4d.utils.SendModelingCommand on one or more target objects.' It goes further than most by disclosing the return-behavior split between geometry-producing and in-place commands and enumerating 16 aliases, which clearly separates it from the generic call_command sibling.

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

Does the description explain when to use this tool, when not to, or what alternatives exist?

The alias list and 'modeling operation' phrasing imply this is the tool for C4D modeling commands, but there is no explicit statement of when to use it over siblings like call_command, nor any exclusions, prerequisites, or target-type caveats. Usage context is implied 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?

No annotations are provided, so the description carries the full burden — and it delivers. It discloses the take-specific edge case ('the Main take itself cannot be moved'), the mutual-exclusivity validation rule, and the return behavior ('Returns the node's new canonical handle so follow-up edits remain stable'). For a mutation tool with zero annotation coverage, this is genuinely rich behavioral disclosure.

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, each earning its place: the first states operations, the second states scope and the kind-matching constraint, the third states the one-of rule, and the fourth covers the take edge case plus return value. Purpose is front-loaded with no filler, though it is slightly 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, the description compensates by stating the return value (canonical handle). Given the tool's complexity — 5 params, a one-of rule, and multi-kind support — all critical operational facts are present. The remaining gap is error/failure behavior for invalid moves (e.g., what happens if the Main take is targeted), which would round it out.

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 each of the 5 properties described, so baseline is 3. The description adds value the schema cannot express: the mutual-exclusivity constraint across parent/before/after/to_root ('Exactly one destination field must be provided') and the per-kind semantics of to_root for takes. This exceeds baseline but the schema still does substantial 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 and resource ('Reparent a node under a new parent, promote it to the top of its hierarchy, or reorder it relative to a sibling') and scopes it to objects/takes/render_data. This clearly distinguishes it from sibling mutation tools like create_entity, remove_entity, and clone_entity, which create or destroy rather than restructure hierarchy, and from set_transform, which changes position rather than hierarchy.

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 context: the supported node kinds, the constraint that siblings/parents must share the moved node's kind, and the one-of destination rule. It does not explicitly name alternative tools to use instead, but the operational constraints effectively bound when the tool applies. A named exclusion would push this to 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 discloses the main side effects: a new document is inserted into the document list and focus switches by default. The edge case about make_active=false being refused on a blank document is covered in the parameter schema, and the description adds the non-destructive context. It does not discuss return values, but none are expected for a creation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences with no filler. The action and the primary use case are front-loaded, and each sentence contributes meaningful information about behavior and purpose.

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 a well-covered schema, the description is complete. It tells the agent what the tool does, the default behavior, and why it is useful. No output schema is needed to understand the call, and there are no hidden prerequisites that would block correct usage.

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 fully documents both parameters. The description reinforces that make_active defaults to switching focus but adds little beyond what the schema states. Baseline 3 is appropriate because the schema carries the parameter documentation burden.

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 action ('Insert a fresh empty BaseDocument'), a precise resource (C4D's document list), and a key behavior (switch focus by default). It also distinguishes itself from destructive alternatives by noting it does not overwrite the current document, which separates it from reset_scene and 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 gives clear context: use this to start a clean scene without overwriting the current one. It does not explicitly name alternative tools or exclusion conditions, but the 'without overwriting' phrasing provides enough situational guidance for an agent to pick it over destructive scene operations.

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 present, the description carries the disclosure burden. It reveals the load-as-new-document behavior, the default focus switch, and the refusal when `make_active:false` would cause destruction of a blank document. It does not fully explain what happens to other open documents, but the central side-effect behavior is covered.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is short and front-loaded with the core purpose. However, the comparison with `import_scene` is stated twice ('Unlike `import_scene`' and 'Differs from `import_scene`'), which is slightly redundant and 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 simple two-parameter, no-output-schema tool, the description covers the core purpose, the distinguishing behavior, parameter defaults, and an important edge case. It is complete enough for selection and invocation, though it omits details about file format support or return behavior, which are not essential here.

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 well. The description adds minimal extra semantic value, mainly reinforcing the default and purpose of `make_active` and the contrast with import. This meets the baseline for well-covered 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 clearly states a specific action and resource: 'Load a Cinema 4D scene file as a new document.' It explicitly distinguishes this tool from `import_scene`, so an agent can tell them apart based purely on the description.

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 direct usage guidance by contrasting with `import_scene`: use `open_document` when you need the file as its own document, not merged into the current one. It also explains the behavior of the `make_active` parameter and the rejection condition, which is strong invocational 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 provided, the description carries the full burden. 'Check connectivity' conveys a read-only, non-mutating intent, but it does not state what the result looks like, whether it sends a fresh request or reports a cached state, or whether any state changes occur. This is acceptable for a simple ping but not richly transparent.

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 a single, front-loaded sentence with no filler. Every word earns its place and directly conveys the tool's purpose.

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 connectivity check, the description is largely complete. It could mention what a successful or failed response indicates, but the simplicity of the tool makes the absence of that detail a minor gap rather than a critical omission.

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 input schema already fully covers this dimension. The description adds no parameter information, but none is needed; the baseline of 4 for a no-parameter tool 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 verb ('check') and a specific resource ('connectivity to the Cinema 4D bridge plugin'). It clearly distinguishes this from the many sibling tools, none of which is described as a connectivity check.

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

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool is used to verify bridge connectivity, but it does not explicitly say when to prefer it over alternatives or when not to use it. The use case is reasonably inferable from the verb, but no exclusions or alternative routing are 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 to fall back on, the description carries the full burden, and it delivers thoroughly. It discloses that the active editor view is temporarily switched to Constant Shading, that it is built freestanding and never inserted, that BaseDraw/camera/time/take are restored in `finally`, and that the result is returned as base64 PNG. This gives the agent an accurate mental model of side effects and safety.

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 but information-dense, with every sentence earning its place: purpose, renderer mode, independence, cleanup, return type, and parameter usage. The most important fact (quick verification render) is front-loaded, and the parameter guidance is packed efficiently without redundancy.

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 output schema, the description fully covers the return format (base64 PNG inline), side effects (state restoration), and parameter semantics. It explains the key limitations (max 4096, parent directory must exist) implicitly through schema descriptions, and the description itself covers the behavioral contract completely. Nothing an agent needs to decide whether to call this tool 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 the description only needs to add value beyond the schema, and it does. It explains the behavior of 'view' presets (auto-framed temp camera), the meaning of 'current', and clarifies that save_path still returns the base64 PNG inline. The only minor gap is that the description does not restate the default/range behavior, but the schema already covers that fully.

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 ('preview render') and resource ('Viewport renderer with Constant Shading Lines'), and characterizes it as a quick agent-friendly verification render. It also differentiates itself from the sibling `render` tool by emphasizing freestanding, non-inserted rendering and inline base64 return, so an agent can distinguish when to use this instead.

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 explains when to use this tool—for quick verification renders—and contrasts it implicitly with other render tools. It provides concrete usage options: 'view' presets for auto-framed temp cameras, 'camera' for named scene cameras, and 'save_path' for disk output, giving clear conditions for each path.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does add one useful behavioral trait: the deletion is 'wrapped in an undo step,' implying reversibility. However, it does not disclose side effects such as whether deleting an entity cascades to children, associated data, or dependent references.

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 a single, front-loaded sentence: the action 'Delete' comes first, followed by the object and a brief parenthetical about undo behavior. Every word contributes meaning, and there is no redundant or filler content.

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 a complex polymorphic handle schema and no annotations or output schema, the description is too thin. It omits guidance on when to choose this tool over related removal tools, what side effects to expect, and how the entity resolution works. An agent would need to infer most operational context from the schema and sibling names.

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 handle parameter is described as 'Entity to delete' and its schema enumerates the supported entity kinds. The description's phrase 'resolved entity' adds mild semantic value by indicating that the handle is resolved to an entity, but it does not go beyond what the schema already conveys.

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 ('Delete') and a resource ('the resolved entity'), making the core purpose clear. It is not a tautology and adds the 'resolved' qualifier, which hints at how the handle works. However, it does not explicitly distinguish this from sibling removal tools like remove_graph_node or remove_xpresso_node, so it falls short of a 5.

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

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided about when to use this tool versus the many sibling tools that also remove or delete things, such as remove_graph_node, remove_user_data, or delete_track. The description simply says what the tool does, leaving the agent to infer appropriate usage from the tool name and context.

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 disclosure burden. It does clearly state the destructive action 'Delete', but it does not mention what happens to connected ports, whether deletion is irreversible, or error behavior for an invalid/missing id. The stable-id note is useful but mostly parameter semantics rather than tool 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 no filler: the first states the operation and target, the second adds the one critical id constraint. The most important information 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?

The schema already documents all parameter meanings, including handle/scope behavior and node_space, and the description supplies the critical id-provenance context. It is mostly complete for a simple deletion tool, though explicit guidance about the document/scene-nodes scope versus material handle path would remove the remaining ambiguity.

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 met. The description adds important meaning beyond the schema by explaining that node_id must be a stable maxon.Id and by naming the exact sources for it (list_graph_nodes or apply_graph_description's $id), preventing the common mistake of passing a display name.

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 action, 'Delete a node by id from a node-material graph', naming the verb, target resource, and identifier type. It also distinguishes this tool from the sibling remove_xpresso_node by scoping it to node-material graphs and references the id's provenance via list_graph_nodes and apply_graph_description.

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 an actionable prerequisite: node_id must be a stable maxon.Id obtained from list_graph_nodes or assigned via $id in apply_graph_description. This tells the agent how to obtain valid input, though it does not explicitly state when not to use the tool or call out remove_xpresso_node as the alternative.

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 explicitly identifies the operation as destructive ('Delete') and adds a key mitigating behavior ('Wrapped in undo'), which tells the agent the action is reversible. It does not cover failure modes or permissions, but for a straightforward delete operation the essential behavioral transparency is present.

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 leads with the action and resource, the second immediately discloses the undo behavior. Every part earns its place, and the most important operational cue (where to get the DescID) is embedded naturally.

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 two-parameter delete tool, the description covers the core call-time needs: what is deleted, how the target identifier is obtained, and that the operation is undoable. The sibling tools (add/list_user_data) complete the workflow picture. Missing explicit return-value or error handling is a minor gap, especially given there is no output 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%, setting a baseline of 3. The description adds meaningful provenance by stating the `desc_id` path is exactly the one returned by `list_user_data` or `add_user_data`, clarifying how to obtain and reuse that parameter. The `handle` parameter is only described as 'Target' in the schema, but the detailed kind-union in the schema compensates. Overall, the description adds a useful layer 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 clear action ('Delete'), a specific resource ('a User Data slot'), and the exact method ('by its DescID path'). It also references the source tools (`list_user_data`/`add_user_data`), which disambiguates this from sibling tools like `remove_entity` and makes the operation immediately understandable.

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 usage context by telling the agent that the DescID path must come from `list_user_data` or `add_user_data`, which effectively sequences the workflow. It does not explicitly mention when not to use the tool or name alternatives like `remove_entity`, so it falls slightly short of 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?

No annotations are provided, so the description carries the full burden. It explicitly discloses that the node is deleted and that all incoming/outgoing connections are severed automatically, which are the critical behavioral side effects. It does not mention return values or invalid-handle behavior, but for a one-parameter destructive tool this is reasonable 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?

The description is two sentences with no filler. The primary action is front-loaded, followed by the handle requirement and the key side effect, all in minimal space.

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 single-parameter destructive operation, the description covers the action, how to source the handle, and the important connection-severing behavior. It does not state whether the deletion is undoable or what is returned, but the absence of an output schema and the single-parameter design keep this gap small.

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 the 'handle' parameter with 100% coverage, but the description adds meaningful semantics by explaining that the handle must point at the target and by pointing the agent to list_xpresso_nodes to discover the path id. This goes beyond the bare schema property text.

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 and resource: 'Delete a GvNode from an Xpresso graph.' This clearly defines the tool and distinguishes it from the sibling 'remove_graph_node' by naming the Xpresso graph 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?

It provides actionable guidance: the handle must be a gv_node handle and the user should use list_xpresso_nodes to discover the target's path id. It does not explicitly contrast with remove_graph_node or state when not to use this tool, so there is slight ambiguity among graph-deletion 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?

With no annotations provided, the description carries the full behavioral disclosure burden. It does disclose that rendering 'may take up to 60 seconds' and that it uses the currently active render data. However, it does not mention whether the call blocks, what it returns, or how it handles existing files at the output path.

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: two sentences, with the core action and scope front-loaded. The prerequisite guidance and timeout note are included without redundancy or 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?

The description covers the primary action, configuration prerequisite, and expected runtime, but no output schema or annotations exist. It does not state the return value or completion behavior after rendering, nor does it guide the agent between this tool and similar siblings like preview_render and rs_render.

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 output_path parameter, so the schema already fully documents it. The tool description adds no additional parameter-specific meaning, matching the baseline for high 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 identifies a specific verb ('Render') and resource ('active Cinema 4D document') and scopes it to 'currently-active render data settings.' However, it does not explicitly differentiate this tool from sibling render-related tools like preview_render or rs_render, so it stops short of full sibling differentiation.

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 helpful context: rendering uses the active RenderData, and users should change settings first via create_render_data or set_params. It does not state when to prefer this tool over alternatives such as preview_render or rs_render, leaving the comparison 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 provided, the description carries the full burden and handles it well. It discloses the destructive nature with 'flushes the undo buffer', 'swaps the active document for a fresh empty BaseDocument (everything goes)', and carefully enumerates what prefix mode does and does not remove. This is unusually transparent for a reset-type 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 three sentences long and every sentence adds critical information: the main action, the prefix-mode behavior, and the performance rationale. It is front-loaded with the primary purpose and avoids redundant wording. The density of technical terms is justified by the complexity of the operation.

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 annotations and no output schema, the description covers the core behavior, both modes, a usage example, and the key side effect (undo flush). The keep_active_rd parameter is only alluded to, and the return value/error behavior is not mentioned, but the 100% schema coverage compensates for the parameter 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 coverage is 100%, giving a baseline of 3. The description adds value beyond the schema by providing a concrete prefix example ('e2e_'), specifying the exact categories affected (objects, materials, non-active render data, non-main takes), and explaining the undo-buffer side effect. The keep_active_rd parameter is only implicitly referenced via 'non-active render data', but the schema fully documents it.

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, 'Clear scene state in one RPC', and then precisely defines two distinct modes (prefix-based partial cleanup and full document reset). It also distinguishes itself from the sibling remove_entity by stating it is 'Much faster than chained remove_entity calls', making its role 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?

It names a clear use case ('cheap cleanup for test suites') and an explicit alternative condition ('Much faster than chained remove_entity calls when cleanup involves animated objects'). It does not provide explicit when-not-to-use guidance, but the context implies it is the bulk-reset choice rather than for fine-grained per-entity removal.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. 'Clear' signals destructive deletion, but the description never explains the required force=true safety gate, whether the operation is undoable, error behavior for unknown documents, or how the optional render_data_name scopes the operation. The only added context is that a document must be explicitly named.

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 zero wasted words: active verb first, then object, then scope qualifier. It is efficient and well-structured, though the length is arguably thinner than 'appropriate' for a destructive tool with a safety gate, preventing a 5.

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 annotations, no output schema, and an unexplained required force parameter, the description is incomplete. Missing: what force confirms, what render_data_name scopes, whether clearing is undoable, and what happens on failure. A 3-parameter mutating tool needs more than one sentence.

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 67%, and the description adds no parameter meaning. The required 'force' parameter is semantically opaque — no schema description, no mention in the description, only const:true. render_data_name's optional scoping behavior is also unexplained, and 'explicitly named document' merely restates document_name's existing schema 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 ('Clear'), resource ('Redshift AOVs'), and scope ('all... from one explicitly named document'). The 'all' qualifier distinguishes it from rs_remove_aov (single-AOV removal), and 'explicitly named document' distinguishes it from active-document operations. An agent can identify the tool and its differentiation from AOV 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?

No when-to-use or when-not-to-use guidance is given, and no alternatives are named even though rs_remove_aov and rs_list_aovs are natural routing candidates. The 'explicitly named document' phrase weakly implies the tool does not act on the active document, but that is an unstated implication rather than explicit guidance.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It does disclose that the tool can both create and update, that the RenderData is 'validated,' and that activation is not implicit. However, it omits important behavioral details such as failure semantics, whether existing RenderData is overwritten, access requirements, or what happens if update_if_exists is false.

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 a single, front-loaded sentence that efficiently conveys the core action and a critical behavioral qualifier. It is appropriately concise, though the term 'validated' is somewhat vague and could be more informative.

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 (11 parameters, nested objects, no output schema, and many related sibling tools), the description is insufficient. It does not address the configuration workflow, the role of update_if_exists, the meaning of validation, or how this compares to closely related tools such as create_render_data. An agent would need substantial additional context to use 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 description coverage is only 18%, and the description does not compensate by explaining any of the 11 parameters. The phrase 'validated Redshift RenderData' gives a general sense of purpose but no concrete detail about fields like frame, width, height, beauty_path, make_active, output_format, or redshift_params. An agent would have to infer parameter meaning mostly from names and the sparse 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 clearly identifies the operation as 'Create or update' a Redshift RenderData and adds the key qualifier 'without implicit activation,' which distinguishes it from simple creation or render tools. However, it does not explicitly name or differentiate itself from sibling tools such as create_render_data, so some ambiguity remains.

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 no explicit guidance on when to use this tool versus alternatives like create_render_data, rs_render, or other Redshift tools. The 'without implicit activation' phrase hints at a use case but does not explain when activation would or would not be desired, and no exclusions or alternative tool names are given.

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

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

With no annotations, the description carries the full burden. It does disclose that the operation creates or updates and only supports runtime properties, but it omits key behavioral details such as what happens when the light already exists and update_if_exists is false, whether an open document is required, and what side effects or return values to expect.

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 filler. Every word contributes either the action, the target resource, or a constraint, making it an economically written definition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is moderately complex with ten parameters, no output schema, and no annotations, yet the description provides almost no contextual coverage. Missing details include required parameter semantics, update behavior, return format, and document prerequisites.

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 only 30%, so the description needs to compensate. It does not explain any of the ten parameters or their roles, and the phrase 'runtime-supported properties' is too generic to clarify which properties are actually settable or how they behave.

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 action (create or update) and a specific resource type (native Redshift light), which distinguishes it from generic creation tools and other Redshift-specific siblings. The qualifier 'using only runtime-supported properties' adds a clear scope constraint.

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