mcp-cinema4d

by kumoproductions

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.3.1
Disambiguation5/5
Each tool has a clear, distinct purpose with minimal overlap. For example, 'render' vs 'preview_render' are differentiated by style and usage, and all entity manipulation tools (create, remove, clone, etc.) target specific actions. Even generic tools like 'batch' have a defined role for grouping operations.
Naming Consistency5/5
Tool names consistently follow a verb_noun pattern using snake_case (e.g., 'save_document', 'list_layers', 'create_entity'). The naming is predictable and intuitive, with no mixing of conventions like camelCase or inconsistent verbs.
Tool Count4/5
With 63 tools, the server covers a broad spectrum of Cinema 4D functionality. While high compared to typical MCP servers (3-15), the count is justified by the complexity of the domain. Tools are well-organized, but some consolidation might reduce redundancy (e.g., multiple graph-related tools).
Completeness5/5
The server provides comprehensive coverage of Cinema 4D operations: document management, rendering, entity CRUD, animation (keyframes, takes, tracks), graph editing (node materials, Xpresso), layers, user data, and queries. No obvious gaps for core workflows are apparent.
Average 4.2/5 across 63 of 63 tools scored. Lowest: 3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 22 commits in the last 12 weeks
- Last stable release on August 10, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that only explicitly passed fields are modified and omitted flags retain their value, which is helpful. It also notes that returned flags reflect post-update state. However, it lacks details on error handling or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff, front-loaded with key information. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 12 parameters and no output schema or annotations, the description is too brief. It omits details on error conditions, default values, and the relationship to other tools like 'set_params'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only 17% schema description coverage, the description adds some value by explaining the partial update behavior, but it does not elaborate on individual boolean flags beyond 'visibility / render / lock'. The color parameter has schema description already.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool toggles layer flags like visibility, render, and lock, which is clear. However, it does not explicitly distinguish it from sibling tools like 'set_params' that could also modify layer properties.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., individual property setters or 'set_params'). The description implies it is for toggling multiple flags at once, but does not state this explicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description mentions undo step but omits safety traits (permanent deletion, permissions, side effects). Insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with action. Efficient but could benefit from more detail without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complex C4D entity system and lack of output schema, the description is too minimal. Does not clarify return values or prerequisites like entity resolution.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds no additional meaning beyond the schema's 'Entity to delete.' Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('delete') and the resource ('resolved entity'), with a distinct verb and object. It differentiates from sibling tools like create_entity or move_entity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use or not use this tool vs alternatives like remove_graph_node. No prerequisites or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Mentions synchronous behavior and timeout in parameter description, but fails to disclose side effects (e.g., destructive commands like 'Make Editable') or error handling. Agents need warnings about potential scene modifications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences that front-load the core purpose and then expand on scope. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description omits return value, status codes, or behavior on failure. For an arbitrary command invoker, it should state that commands may mutate document state and that success/failure feedback is expected.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so description adds limited value beyond the schema. Provides example command IDs and a hint about increasing timeout for long-running commands, but does not explain subid or command_id semantics beyond what is already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action: invoke a Cinema 4D command by plugin id via c4d.CallCommand(). Provides examples of built-in commands (render, save, make editable) and mentions it works with registered plugins, distinguishing it from sibling tools like modeling_command or render.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives examples but no explicit guidance on when to use this tool vs alternatives like modeling_command or render. Lacks context about prerequisites, when not to use it, or trade-offs between tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It explains the creation/update mechanism and avoids manual parameter handling, but omits side effects (e.g., overwriting existing tags, permissions, or return value). The behavioral description is too minimal for a mutation tool without annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is extremely concise: three sentences, front-loaded with the primary action and key behavior. No wasted words. Benefits and projection aliases are listed efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters and no output schema, the description covers the main purpose and update behavior, but does not mention optional UV or restriction parameters. It is adequate but not fully complete; a summary of optional features or return value would improve it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds little: it repeats the projection enum values and references `update_if_exists`. It does not elaborate on parameters like `uv_tiles`, `uv_offset`, or `restrict_to_selection`. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the core action: 'Link a material to an object by creating a Texture tag'. It also specifies the update-if-exists behavior. No sibling tool duplicates this functionality, so it is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. It does not mention prerequisites, when to set `update_if_exists`, or compare to other material assignment methods. Usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description partially fills the gap by noting that FPS and frame range are mirrored onto active render data. However, it lacks details on other behavioral aspects such as permissions, side effects, or validation for parameters like active_camera or active_take.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that immediately states the purpose and lists the affected settings, with no redundant or extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description should provide more context about return value, required permissions, and parameter constraints. It only covers the purpose and one behavioral note, leaving significant gaps for a tool with 6 parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 minimal value beyond listing the parameters already described in the schema. No new semantic information is provided for individual parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Update' and the resource 'document-level settings', listing the specific settings (fps, frame range, current frame, active camera, active take). This distinguishes it from sibling tools like set_params or set_transform.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs. alternatives. The description does not mention prerequisites, when not to use it, or compare it to other update tools among the siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It only states 'Delete a node,' but does not disclose side effects, reversibility, permissions, or what happens to connections. For a destructive operation, more transparency is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: the first defines the purpose, the second adds essential detail about the id. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is present, so the description should explain return values or confirmation, which it does not. It is adequate for a simple deletion but lacks information on success/error behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds minimal extra meaning beyond the schema, only reinforcing the node_id constraint. It does not explain scope, handle, or node_space parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Delete a node by id from a node-material graph,' specifying the verb and resource. It distinguishes from sibling tools like list_graph_nodes and apply_graph_description by focusing on deletion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly mentions that the id must come from list_graph_nodes or apply_graph_description, providing clear context for when to use. However, it does not offer exclusions or alternatives for non-graph node removal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states the tool evaluates the scene at each frame and restores the original playhead (via restore_time parameter). However, it does not disclose potential side effects, execution cost, or guarantees about idempotency. No annotations are provided, so the description partially bears the burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short (two sentences) and front-loaded with the core action. It avoids redundancy, but a slightly more structured breakdown (e.g., listing limitations or expected output) would improve it.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should clarify what the return value looks like (e.g., dictionary per frame, structure). It only says 'return the object's transform' without detailing format or the number of entries, leaving ambiguity for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 6 parameters have schema descriptions (100% coverage), so the baseline is 3. The tool description does not add additional meaning beyond what is already in the input schema, such as clarifying the interaction between parameters or output format details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool evaluates the scene at each requested frame and returns the object's transform. The use case for verifying alembic/constraint/xpresso-driven animation is explicitly given, and the purpose is distinct from sibling tools like get_mesh or set_transform.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates it's useful for verifying animation without writing a custom exec_python sampler, but does not explicitly mention when not to use or contrast with siblings like set_transform or get_mesh.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It states it wraps internal functions (take.OverrideNode + UpdateSceneNode + override[descid] = value) and is a write operation, but does not disclose idempotency, error handling, whether prior overrides are replaced, or effects of clear/remove_all parameters. Schema descriptions cover some of these, but the description adds minimal behavioral insight beyond purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences front-load core action and target types, then wrap internal detail and use case. No redundant information; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without output schema, description omits return type/status and error conditions. It covers purpose and use case well but doesn't address take existence requirement or parameter interactions (clear/remove_all). Adequate given schema covers parameter details, but some operational context missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, baseline 3. Description adds context that paths use set_params syntax, which aids agent understanding. No further parameter-level elaboration is needed given schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool writes per-Take parameter overrides onto a target node, listing supported node types (object, tag, material, etc.). It differentiates from sibling set_params by emphasizing shot-by-shot variation use (e.g., override Focal Length per Take) and noting path syntax matches set_params.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this for shot-by-shot variations that share a single scene' and provides a concrete example (Focal Length override). References set_params for path syntax, guiding input. Lacks explicit 'when not to use' or alternatives, but context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 mentions the return value and dtype aliases, but does not disclose side effects, permissions, or error conditions. For a mutation tool, more detail would be helpful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the purpose. It is efficient but could be slightly more structured (e.g., separating the return value note).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters and no output schema, the description provides a good high-level pattern but lacks details on validation, error handling, and constraints. The schema covers parameters well, making the tool usable but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 each parameter. The description adds the dtype alias list and the piping pattern, but does not add significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add a new User Data slot'), the target ('BaseList2D'), and the pattern ('common rigging / control-exposure pattern'). It distinguishes from sibling tools like list_user_data and remove_user_data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the intended use case ('common rigging / control-exposure pattern') and tells the agent that the returned DescID can be piped into get_params / set_params. It does not explicitly state when not to use it, but the context is sufficient for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It implies a read-only operation via 'Return', but does not explicitly state that it has no side effects, nor does it mention error conditions or permissions. For a simple query this is adequate but not exemplary.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, front-loading the key action and result.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and no output schema, the description covers the core functionality. However, it could be slightly more complete by clarifying the return format (e.g., layer name or ID) or providing an example, but it's nearly sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds minimal value beyond the schema's 'Entity to query.' It briefly lists entity types (already in schema) and mentions the null return, which is about the output, not the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Return' and the resource 'layer currently assigned to a target entity', listing the entity types (object, tag, material) and the null case. It distinguishes from sibling tools like assign_to_layer (which sets layers) and list_layers (which lists all layers).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (when you need the layer of an entity) but provides no explicit guidance on when to use this tool versus alternatives like assign_to_layer or list_layers, nor any preconditions or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description bears full burden. It describes the return data but does not mention whether the operation is read-only, has side effects, or requires specific permissions. It is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences. The main action is front-loaded, and every phrase adds necessary detail without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool with no parameters and no output schema, the description covers the returned fields and scope (active document). Minor omission: no mention of ordering or filtering, but not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so baseline is 4. The description adds value by detailing the returned fields (name, color, flag dict), which is not in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Enumerate' and clearly identifies the resource as 'every LayerObject in the active document'. It distinguishes itself from sibling layer tools like create_layer, assign_to_layer, get_object_layer, and set_layer_flags.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., get_object_layer). It only describes what it does, not when it's appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that vector tracks appear as separate entries per component, which is a behavioral detail. However, it does not mention potential side effects, permissions, or rate limits. The read-only nature is implied but not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no redundancy. First sentence states the action and return shape; second adds a critical behavioral detail about vector tracks. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single parameter and no output schema, the description covers the return format, chaining possibilities, and special-case handling of vector tracks. It lacks information on ordering or limits, but those are minor for a simple enumeration tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents the handle parameter well. The description does not add further meaning beyond the schema, which is acceptable per guidelines. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool enumerates CTracks on an entity, specifying the return fields and even chaining hints. It's not a tautology and distinguishes itself from other listing tools via its focus on animation tracks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing tracks but does not explicitly state when to use versus alternatives (e.g., when not to use list_tracks). It provides chaining guidance (pipe into get_keyframes/set_keyframe), which is helpful, but no exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It only states 'check connectivity', without detailing return behavior, error handling, or side effects. For a simple tool, a bit more context would be helpful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no unnecessary words. It is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no parameters and no output schema, and the complexity is low. The description is adequate for a basic ping tool. It could mention the response format, but for its simplicity, it is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, and the description adds no parameter information. With 100% schema coverage and 0 params, baseline is 4. The description does not need to elaborate on parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('check') and resource ('connectivity to the Cinema 4D bridge plugin'), clearly defining the tool's purpose. It distinguishes from sibling tools like render or save_document which have different actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage as a connectivity check, which is clear, but it provides no explicit guidance on when to use this tool versus alternatives or any prerequisites. For a simple ping tool, this is acceptable but not proactive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the idempotent update behavior and configuration options, but does not mention error cases (e.g., duplicate name without update_if_exists) or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the main action, and contains no extraneous information. Every word serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with 4 parameters and nested objects, the description is adequate but lacks details on what happens when a layer with the same name exists without 'update_if_exists'. No output schema is expected, but return behavior is not clarified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by providing examples (color with range 0..1, flags object with key names) and explaining the idempotent behavior of 'update_if_exists', which goes beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the verb 'Create' and the resource 'LayerObject' at the document's layer root, clearly distinguishing it from sibling tools like 'set_layer_flags' or 'assign_to_layer'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for layer creation and mentions the 'update_if_exists' flag for idempotent updates, but does not explicitly state when to use this tool versus alternatives or provide exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that new takes are checked by default and that update_if_exists exists, but does not explain idempotency, merge behavior, side effects, or failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, tightly written. First sentence defines function, second explains a key default, third states return value and use case. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 9 parameters, no output schema, and no annotations, the description could be more complete. It covers overall purpose and one default, but does not explain interactions between parameters (e.g., clear_camera vs camera) or update behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%. Description adds value beyond schema by noting default checked state and the ability to override. This clarifies intent and behavior beyond the basic parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool creates or updates a Take, combining multiple operations. It distinguishes from siblings like 'take_override' by bundling AddTake, SetCamera, SetRenderData, and SetChecked.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context for use, such as default checked state and ideal for building take stacks. However, it does not explicitly mention when to use this tool versus the sibling 'take_override' or other alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description covers basic behavior: it dumps parameters and lists what is returned. However, it does not address side effects, error conditions, or return format details. The behavioral disclosure is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences—one for purpose, one for usage guidance. No redundant words or filler. Efficiently communicates the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complex handle parameter and lack of output schema, the description does not fully describe the return structure beyond listing fields. For a data-dumping tool, more detail on the output format would improve completeness. Still, it covers the core need for parameter discovery.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds that the entity is 'resolved by handle' but does not elaborate on the handle syntax beyond what the schema already details. The schema itself provides extensive parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Dump all description parameters of a C4D entity' with a specific verb and resource. It contrasts with sibling tools like get_params and set_params by emphasizing discovery of parameter IDs before reading/writing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Use this to discover parameter IDs before reading/writing' provides clear context for when to use the tool. It does not explicitly mention when not to use or list alternatives, but the purpose implies its role among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the return type (flat list) and a specific error indication (supported:false), but lacks details on side effects, return structure (node objects), or performance implications. Partial but not complete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the main action, no redundant words. Efficiently communicates key usage and a special return case.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters and no output schema, the description covers core usage but omits the structure of individual nodes in the returned list and prerequisites like an open document. It is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by clarifying the exclusive usage of handle and scope, the default node_space values, and the condition for handle requirement. This exceeds basic schema info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it walks a node graph and returns a flat list of nodes. It distinguishes between material and document graph modes, which differentiates it from sibling tools like list_graph_node_assets or get_graph_info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains two modes (material handle vs. document scope) and mentions a supported:false return for failure cases, but it does not explicitly compare with alternatives or state when not to use this tool. The guidance is present but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses return behavior (handles for new geometry, mutated targets for in-place) but lacks details on side effects, error states, permissions, or other behavioral traits, with no annotations to augment transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with purpose, then behavioral differentiation, then aliases, with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (4 params, nested targets, no output schema), the description covers purpose and aliases but lacks details on target specification, error handling, and return format for all command types.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, the baseline is 3, but the description adds value by enumerating command aliases and clarifying the behavioral difference, going beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool runs a Cinema 4D modeling operation via SendModelingCommand on target objects, distinguishes between commands that produce new geometry vs in-place mutations, and lists numerous aliases, making it distinct from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for modeling commands and provides aliases, but does not explicitly state when to use this tool versus alternatives or mention prerequisites, leaving implicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses key behaviors: operations applied in order, default fail-continue mode, and wrapping in a single undo group. It also warns against nesting batch. However, it does not describe the return format or error reporting structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences with no redundancy. The first sentence conveys the main purpose, the second adds behavioral details, and the third provides usage context. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, key behaviors, and a usage pattern, which is adequate given the tool's moderate complexity. However, it omits details about the return value structure (e.g., per-op results) and doesn't explain how errors are surfaced beyond 'recorded per op'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds valuable context by explicitly forbidding nested batch in the ops parameter, which is not in the schema. This constraint-and-context adds meaning beyond the basic parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Run many generic ops in one RPC', identifying the verb and resource. It distinguishes the tool's purpose from individual operation tools by emphasizing batching, but does not explicitly contrast with specific siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a concrete use case ('apply X to all matching entities' workflows) and suggests pairing with list_entities, offering clear guidance. It also notes that batch itself is not allowed inside batch, but lacks explicit when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses the 'update-if-exists' behavior and return handle, but lacks details on side effects like overwriting existing data, error cases (e.g., name exists without update_if_exists), or permissions. It is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no fluff: the first conveys core action and parameters, the second adds return value and chaining. Every phrase earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 12 parameters and no output schema, the description covers key aspects (upsert behavior, return handle, chaining). It omits parameter interaction details (e.g., frame_sequence defaults) and error handling, but schema fills many gaps, making it fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema thoroughly defines each parameter. The description adds little beyond grouping parameters (resolution, renderer, fps, frame range) and noting chaining, providing marginal extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create or update-if-exists') and the resource ('RenderData'), listing key parameters (resolution, renderer, fps, frame range) in one call. It also mentions the return value and chaining with sibling tools, distinguishing it from general 'create_entity'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use as an entry point by mentioning 'one call' and chaining with 'create_take/set_params'. However, it does not explicitly state when to use this tool versus alternatives like 'set_params' for modifications, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It states the return format ('{removed, track}') and implicitly indicates a destructive operation, but does not mention prerequisites, side effects, or permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficient: four sentences, no redundant information, and the main action is stated upfront.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description provides the return format. It also references the symmetric counterpart. However, it does not explain how to obtain 'handle' and 'param_id', relying on schema descriptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds value by clarifying that 'frame' is for single-frame delete and 'start_frame'/'end_frame' are for a range, implying mutual exclusivity beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Remove keys') and the resource ('a CTrack'), and explicitly mentions symmetry with 'set_keyframe', which distinguishes it from siblings like 'delete_track'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains how to use parameters (single frame vs range), but does not provide guidance on when to use this tool versus alternatives like 'delete_track' (which removes an entire track) or 'get_keyframes'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It states the action ('remove') and return value, but lacks details on side effects (e.g., whether all keyframes are removed, if the action is reversible, or required permissions). The description is adequate but not comprehensive for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two clear, front-loaded sentences. The first sentence states the primary action and the second specifies the return format. Every word serves a purpose, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explicitly states the return value. It mentions the target via the 'handle' parameter but relies on the schema for details. The description is sufficient for a simple delete operation, though it could provide more context about the relationship between tracks and keyframes or how to construct the handle for different target types.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (all parameters described in the input schema). The description additionally clarifies that the track is identified by 'param_id' and the optional 'component' for vector tracks, which adds helpful context beyond the schema's descriptions. This extra clarification justifies a score above the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The tool name 'delete_track' and title 'Delete Animation Track' clearly indicate a delete operation on a track. The description specifies 'Remove an entire CTrack', which is a specific verb and resource. It distinguishes from sibling tools like 'delete_keyframe' which removes individual keyframes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when one wants to remove an entire track identified by param_id and optional component. However, it does not provide explicit guidance on when to prefer this tool over alternatives (e.g., using delete_keyframe for individual keyframes) or mention any prerequisites or restrictions. The context is implied but not directive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must handle transparency. It describes the output (node spaces, active space, alias table) but does not disclose read-only nature, error behavior, or side effects. Adequate but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no extraneous information. The first explains the tool's output, the second provides usage context. Efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose, output, and workflow context (use before apply_graph_description). Lacks details on return format, error handling, and prerequisites, but for a simple read tool with one param, it is fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (the only parameter 'handle' is documented). The description does not add parameter-specific details beyond the schema, which is acceptable per baseline but does not add extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reports which node spaces a material exposes, the active one, and the alias table. It also distinguishes itself by mentioning use before `apply_graph_description`, differentiating it from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this before `apply_graph_description` to confirm the right `node_space` is addressable,' providing clear context and an alternative tool. It lacks explicit when-not-to-use guidance but is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool dumps raw container data including hidden keys, and suggests filtering. It does not mention read-only nature or potential size of output, but the behavior is mostly transparent for a dump tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences that are front-loaded with the core purpose and a practical usage tip. Every sentence serves a clear function, with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 well-described parameters and no output schema, the description covers the purpose but omits information about the return format or potential data volume. For a dump tool, it is adequate but could hint at the output structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining the purpose of the id_from/id_to parameters ('Filter by key range to narrow output'), which goes beyond the schema's type constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool dumps the raw BaseContainer of a C4D entity, including hidden keys not shown in describe, and mentions filtering by key range. This verb and resource are specific and distinguish it from siblings like describe or get_params.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (to see hidden keys) and provides a tip on filtering. However, it does not explicitly state when not to use or name alternatives, though the context of sibling tools makes the purpose clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose all behavioral traits. It covers the core action (merge into active document), return value (newly-imported objects), and optional operations (reparent, rename). However, it omits details about side effects on existing scene content, error conditions (e.g., file not found, unsupported format), and whether all file types are treated equally. For a mutation tool, more transparency would be expected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the core purpose. Every clause adds value: file formats, internal method name, return value, chaining hints, and optional behaviors. No redundant or vague language.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has four parameters, no output schema, and no annotations, the description covers primary use cases but lacks details on return value structure, error handling, and behavior under edge cases (e.g., merging into an empty document, duplicate names). It is adequate for typical use but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so each parameter already has a description. The tool description adds significant workflow context beyond the schema: it explains that the return value enables chaining with other tools and that the 'parent' and 'rename' parameters operate on the imported objects. This helps the agent understand how parameters integrate with the overall process.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool merges an external file into the active document, lists supported formats (abc/fbx/obj/c4d/etc.), and distinguishes from siblings as the only import/merge tool. The verb 'Merge' and resource 'external file into active document' are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that the returned objects can be chained with set_params, create_entity, or create_take, providing clear workflow guidance. It also mentions optional reparenting and renaming. However, it does not explicitly contrast with alternatives like open_document (which opens a new document) or warn about potential conflicts when merging.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals the internal payload building and type coercion for vectors, which adds some value. However, it does not discuss return values, error handling, or mutation persistence, leaving gaps given no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three front-loaded sentences, each earning its place: purpose, relation to sibling, and a key type detail. No extraneous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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 lacks info on return values and error scenarios. Schema covers params, but guidance on targeting the material graph (scope vs handle) is minimal.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, baseline is 3. The description adds extra meaning by clarifying that 3-number arrays become maxon.Vector and providing port path examples, going beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Update a single port on a node' with a specific verb and resource. It distinguishes itself from apply_graph_description by positioning as a thin convenience, and from set_xpresso_port by targeting material graphs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains it is a convenience over apply_graph_description, implying when to use it. However, it lacks explicit when-not-to-use or alternative scenarios like setting multiple ports.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description covers key behavioral aspects: atomic writes, undo wrapping, auto-coercion of vector values, and the return format with applied and error lists. However, it omits side effects like modifying the scene, permission requirements, or whether the operation is reversible (though undo is mentioned).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is fairly concise, front-loading purpose and then detailing format and behavior. Every sentence adds value, though it could be slightly shorter without losing essential info.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description includes the return format. It covers input format, auto-coercion, and error handling. It does not mention document state requirements or handle validation, but the schema provides handle details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description adds meaning beyond the schema by explaining that path can be an int id or DescID path with examples, and that list of 3 numbers auto-coerce to vectors. Schema coverage is 100%, so baseline is 3, but the added context raises it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it atomically writes parameter values with undo wrapping. It specifies the input format as an array of {path, value} objects and provides examples, making the verb and resource very specific. Among siblings like get_params and describe, this tool is distinctly for writing parameters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for batch parameter writes with undo, but does not explicitly contrast with alternatives like get_params or set_keyframe. No guidance on when not to use it or prerequisites is provided, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It discloses creation/mutation behavior, the effect of scope and create_graph parameters, and the syntax. However, it does not detail side effects (e.g., overwriting existing connections) or failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense paragraph that covers all essential points without redundancy. It could be improved by using bullet points or separate sections for clarity, but it is appropriately sized and front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 params, nested objects, two graph types, no output schema), the description is thorough. It covers syntax, scope differences, and type constraints. Missing return value info is acceptable since no output schema exists, but explicit mention would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 100% schema coverage, the description adds significant value: it explains the declarative dict syntax with $type/$id/-> keys, provides an example, clarifies the handle requirement vs scope, and defines node_space aliases and create_graph defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool builds or mutates a node graph using a declarative dict syntax, and distinguishes itself from sibling graph tools (set_graph_port, remove_graph_node) by its bulk declarative approach. It specifies supported graph types (material, scene-nodes) and provides an example.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool (for building node graphs via declarative dicts) and provides guidance on choosing between material vs document scope. It also warns against using corenode IDs for scene-nodes. However, it does not explicitly contrast with alternatives like set_graph_port or remove_graph_node.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations were provided, so the description bears the full burden. It details what data is captured (type_id, type_name, name, file field, file_candidates, linked_shaders) and the heuristics used. However, it does not explicitly state that the operation is read-only or mention any side effects or permissions needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with bolded phrases for emphasis and a logical flow. It is slightly verbose but remains focused and informative, making good use of front-loaded key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (recursive shader tree with heuristics) and the absence of an output schema, the description partially describes the output format but does not fully specify the JSON structure or all possible fields. It covers the main points but leaves some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already fully documents both parameters (handle and max_depth). The description adds minimal extra context beyond the schema; it mentions that handle should be a shader handle but does not elaborate further.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool recursively dumps a shader into JSON, specifies it is for classical materials only, and distinguishes from node material tools like list_graph_nodes. It also mentions the captured fields and heuristics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly explains when to use this tool (classical materials) versus alternatives (list_graph_nodes for node materials). Also recommends pairing with list_entities kind=shader to discover handles.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description reveals a key behavioral trait: it forces a scene pass to populate data. It also describes the return structure and error condition. However, it does not explicitly state it is read-only or detail performance impacts.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with four sentences, each serving a distinct purpose: purpose, behavioral detail, return format, and unsupported conditions. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has moderate complexity, no output schema, and no annotations, the description covers the essential points: purpose, behavior, return structure, and failure modes. It lacks mention of any prerequisites or side effects beyond the scene pass, but is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds context about the handle parameter (must be MoGraph generator) but does not elaborate on max_count or include_matrix beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Read') and clearly identifies the target resource ('per-clone transforms from a MoGraph generator'), with examples of valid generators. The scope is well-defined, distinguishing it from general transform tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when the tool is appropriate (for MoGraph generators) and notes when it is not supported. It implies the tool is for clone data, but does not name alternative tools for non-MoGraph objects.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description assumes full burden. It describes the output structure (plugin and plugin_file fields) but does not mention side effects, error behavior, or performance considerations. Transparency is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences front-loaded with the purpose, then details. Every sentence adds value; no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 a good level of completeness by explaining the output structure and filtering options. Minor gaps remain (e.g., whether all or only installed plugins are listed, sorting behavior), but it is largely sufficient for a plugin enumeration tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has 100% description coverage for parameters, but the description adds meaningful context beyond the schema by explaining what 'plugin' and 'plugin_file' represent and how plugin_pattern works. This adds value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Generalized plugin enumerator' and specifies it can list plugins of any type by passing a plugin_type string alias or integer. It distinguishes from sibling tools like 'call_command' and others that are not plugin enumerators.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains how to use plugin_type, name_pattern, and plugin_pattern for filtering, giving clear context. It does not explicitly state when not to use this tool, but among sibling tools there is no alternative plugin enumerator, so the guidance is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description adds return format but does not disclose safety (e.g., read-only, permissions, side effects). Adequate for a simple enumeration but missing behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences front-loading the action and return format, with zero wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple enumeration tool with one parameter and no output schema, the description covers purpose, return structure, and downstream usage. Lacks error handling or edge cases but sufficient for selecting and invoking the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description covers the handle parameter minimally ('Target to inspect.'). The tool description adds value by explaining the return structure and how desc_id is used, compensating for the schema's brevity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Enumerate') and resource ('User Data slots on a target'), and specifies the return fields {desc_id, name, dtype, value}, distinguishing it from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context: enumerate user data slots and feed desc_id into downstream tools. Lacks explicit when-not-to-use or alternatives, but the specific use case is well-defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full weight. It discloses the core behavior (inserts new document, switches focus by default) but does not mention potential side effects like unsaved changes in active document. The phrase 'without overwriting' implies safety, but more detail (e.g., warnings, memory) would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, 30 words, no fluff. Every sentence adds essential information: what the tool does and when to use it. Well front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 parameters and no output schema, the description covers the main aspects: action, effect on focus, and use case. It could mention return value or error handling, but overall it is sufficient for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter descriptions, so baseline is 3. The description adds value by stating 'Optional display name' and clarifying the default for make_active ('Default true'), which helps the agent understand behavior without looking at schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verb 'Insert a fresh empty BaseDocument' and clarifies the tool's role versus sibling tools like open_document or close_document, making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states the tool is 'useful for starting a clean scene without overwriting the current one'. It provides clear context for when to use, though it does not explicitly list exclusions or alternatives. Given the sibling list, the user can infer that open_document is for existing files.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that connections are automatically severed, which is important behavioral info beyond the name. However, it omits details like handle invalidation, undo behavior, or error conditions. Without annotations, more could be added.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first states the core action, second provides prerequisite and side effect. No filler; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 required param, no output schema), the description covers handle acquisition, automatic connection removal, and references a sibling tool. Missing permissions or error handling, but still fairly complete for a delete operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides a description for the handle parameter, but the description adds extra context: the handle must point to the target and how to discover its path id via list_xpresso_nodes. This adds meaningful guidance beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Delete a GvNode from an Xpresso graph' and directly references the prerequisite tool list_xpresso_nodes. The title is consistent and distinguishes from sibling tools like remove_graph_node and 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.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use the tool and how to obtain the required handle, but does not exclude cases where other tools (e.g., remove_graph_node) might be more appropriate. However, the context is clear for Xpresso-specific deletions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It discloses critical behaviors: required absolute path, parent directory existence, supported formats with defaults, and Save-As-Copy behavior. However, it omits details like overwrite policy or failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The main action is front-loaded, followed by clear constraints and options. Every sentence adds necessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description covers the tool's primary behavior, format options, and a key parameter. It is sufficient for most use cases, though it lacks details on return values or side effects like file overwriting.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, providing a baseline of 3. The description adds value by explaining the copy parameter's Save-As-Copy behavior and listing format aliases (e.g., 'alembic' for abc). It also adds path constraints not in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Save the active document to disk' with a specific verb and resource. It lists supported formats and explains copy behavior, clearly distinguishing the tool's purpose among siblings like open_document or import_scene.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
While it specifies prerequisites (absolute path, parent directory must exist) and explains the copy parameter, it does not provide guidance on when to use this tool versus alternatives such as import_scene or open_document. The context is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the automatic creation of CTrack on first use and explains dtype inference. However, it does not mention error conditions, return values, or whether the operation is idempotent (though 'update' implies it is). The side effect of creating a track is disclosed, but more details on failure modes would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, with no redundant information. The first sentence clearly states the core action, and the second adds essential details about parameter types and automatic track creation. Every word earns its place, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 8 parameters and no output schema, the description covers the main functionality well, including dtype handling and automatic CTrack creation. However, it does not explain the structure of the handle parameter (though schema does) or address what the tool returns (e.g., success indication). For a mutation tool with no output schema, these details would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All parameters are described in the schema (100% coverage), so baseline is 3. The description adds value by explaining the context of dtype inference and the types of parameters supported (scalar and vector), which goes beyond the individual parameter descriptions. This helps an agent understand how the parameters relate to each other.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Create or update') and the resource ('a single keyframe on a resolved entity's parameter'). It also distinguishes from sibling tools like get_keyframes (read) and delete_keyframe (remove) by focusing on creation/update and mentioning automatic CTrack creation, which is unique among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides guidance on parameter types (scalar and vector) and explains that dtype can be inferred or overridden, which helps in deciding when to use the override. However, it does not explicitly state when not to use this tool versus alternatives (e.g., set_params) or prerequisite conditions like entity resolution.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool replaces the selection and clears existing selection of the specified kind first. Without annotations, this covers the core mutation behavior. However, it does not mention error handling, validation of indices, or other side effects (e.g., destructive nature beyond clearing).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, each earning its place: the first states the primary action and clearing behavior, the second provides a usage guideline. No waste, front-loaded with key action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 essential behavior, parameters, and complementary usage. It lacks error or validation details but is sufficient for a simple set tool. The sibling context suggests many related tools, but the pairing note helps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter descriptions, but the description adds value by clarifying that the tool clears existing selection before setting new indices, which is not in the schema. The pairing note also adds context for the 'indices' parameter's purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Replace' and the resource 'BaseSelect on an editable mesh', specifying the selection kinds (point/polygon/edge) and that existing selection is cleared first. This distinguishes it from sibling tools like 'set_selection' and 'get_mesh', which are mentioned.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit pairing advice: use with 'get_mesh' using 'include:["selections"]' to read channels back. This guides the agent on complementary usage. However, it does not explicitly contrast with alternatives like 'set_selection' or state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses filtering behavior for scene-nodes and possible supported:false return. For a read-only listing tool, this 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with purpose, followed by nuance and edge case. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks explicit description of the output format (list of strings or objects) and details on response shape, though purpose is clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and description adds alias names and default for node_space parameter, adding meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it enumerates node-template asset ids for a node space, and distinguishes from sibling tool list_graph_nodes that reports existing nodes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explains context: ids are for apply_graph_description, filtering for scene-nodes, and mentions supported:false edge case. Does not explicitly state when not to use, but gives enough guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It mentions 'Wrapped in undo', indicating the operation is reversible within the undo stack. However, it does not specify if the deletion is permanent after undo stack clearance, or if there are any side effects, which would be valuable for a deletion tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the essential information with zero waste. Every word is purposeful, making it highly efficient for an AI agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple deletion tool with no output schema, the description covers the core operation, identifies the required parameter source, and notes the undo behavior. No critical information is missing, making it complete for the 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already describes desc_id as a DescID path. The description adds value by explicitly linking desc_id to the output of sibling tools (list_user_data or add_user_data), which helps the agent understand how to construct the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Delete a User Data slot by its DescID path', using a specific verb and resource. It distinguishes from siblings like add_user_data and list_user_data by referencing their return values, making the tool's exact function unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells the agent that the desc_id parameter should be obtained from list_user_data or add_user_data, providing a clear retrieval path. It also notes 'Wrapped in undo', implying safe usage. However, it does not explicitly state when not to use this tool or mention alternatives for similar operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden. It explains that the tool creates nodes and wires connections in one call, accepts operator_id as int or alias, and optionally creates a Texpresso tag. It could further detail side effects or error handling, but current coverage is good.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at 4-5 sentences, front-loaded with the core concept and key differentiators. Every sentence adds meaningful information without redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of nested objects and absence of an output schema, the description covers purpose, parameters, and an example. It does not mention return values or error states, which are minor gaps, but overall it is adequately complete for a builder tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters, so the description already adds value by listing operator_id aliases and providing an example usage. This goes beyond the schema's self-documentation, aiding the agent in constructing valid input.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a 'declarative builder for an Xpresso graph' and explicitly distinguishes it from 'apply_graph_description' for Maxon node materials. It uses specific verbs like 'creates nodes' and 'wires connections', making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by comparing to sibling tool 'apply_graph_description' (for Maxon) and mentions when to create a tag if missing. However, it does not explicitly state when not to use this tool or provide alternatives for similar tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries burden. It reveals essential behavior (null clears, layer must exist) but does not disclose overwrite behavior, side effects, or error handling. Adequate but limited.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no waste, front-loaded with purpose, action, and key condition. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given simple tool with 2 params and no output schema, description covers prerequisites and clearing. Lacks details on outcomes or errors, but sufficient for common use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3. The description adds value by explaining layer's null use and summarizing target types, going beyond schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool places a target on a named layer, listing target types (object/tag/material) and action of assigning to a layer. This distinguishes it from siblings like create_layer or list_layers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use (layer must exist) and provides guidance to call create_layer first if needed, and how to clear assignment with null. This helps in decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden. States it returns a handle for chaining, mentions object handles include path for stable re-resolution. Notes position is for objects only. Could be more explicit about side effects or permissions, but covers key behavioral traits adequately.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise, front-loaded with main purpose. Every sentence adds essential information. No redundancy or filler. Well-structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given complexity (7 params, nested objects, no output schema), description covers main points: kinds, parent requirements, return value, special notes on shader. Could elaborate on slots or error handling, but overall sufficiently complete for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. Description adds value beyond schema: explains shader kind targets classical chains, type_id accepts aliases for objects, position is relative. These details help the agent use parameters correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it is a unified constructor for object, tag, material, shader, video_post. Uses specific verb 'create' and lists key capabilities like parent linking, params, positions, slot assignment. Distinguishes from sibling apply_graph_description by noting it is for classical shader chains, not node-material edits.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use apply_graph_description instead for node-material edits. Notes parent requirements for different kinds (required for tag, shader, video_post; optional for object). Implicitly distinguishes from other creation tools by being the unified constructor.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly states this is a read operation ('Read'), which implies no side effects. It mentions the return format `[{frame, value, interp}]` and the optional clipping, providing clear behavioral expectations without annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, each earning its place: the first states the main action and usage hint, the second details optional parameters and return format. No fluff, front-loaded with the primary purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 6 parameters and no output schema, the description covers the core purpose, parameter semantics, and usage hints. It briefly mentions the return format, which is sufficient for a read-only tool. Could elaborate on return structure, but overall complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds meaning by explaining the handle as an 'animated entity,' clarifying start_frame/end_frame as 'inclusive,' and distinguishing component usage for vector vs scalar tracks. This adds value beyond the schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Read the keys on a specific animation track,' which is a specific verb-resource pair. It distinguishes itself from sibling tools like list_tracks (discovery) and delete_keyframe (mutation) by focusing on reading keyframes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises using list_tracks to discover param_id and component pairs, and notes that start_frame and end_frame clip the range. It lacks explicit when-not-to-use or alternatives, but the guidance is clear for the common use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description describes a read operation ('Read') and notes that it returns canonical handles for piping. It does not mention edge cases (e.g., no active document) but is generally transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words, front-loaded with the core purpose. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description adequately explains the return values and use case. It could mention behavior when no selection exists, but is otherwise complete for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters. The description adds no parameter-specific information, but the baseline for no parameters is 4, and there is no need for additional param details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads the active document's current selection and lists the specific components (active object, all selected objects, active tag/material). This distinguishes it from siblings like 'set_selection'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states it's useful for reacting to the user's focus without re-picking, providing a clear use case. It implies but does not explicitly state when not to use it or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description carries full burden. Discloses read-only nature, output format (flat list, id, port summaries), and handle resolution behavior. Does not mention performance limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff. Front-loaded with main action and output. Second sentence concisely explains id usage and accepted inputs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, description covers purpose, output structure, id usage, and handle types. Adequate for a list tool with moderate complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a complex union. The description adds semantic value by summarizing the two main handle types (tag handle or object handle) and clarifying fallback behavior (uses first Texpresso tag).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Walk... and return a flat list' and the resource 'its GvNodes', with explicit aliases (Texpresso/GvNodeMaster). This distinguishes it from sibling 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.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on using the returned `id` to address nodes in other tools (apply_xpresso_graph, etc.), and explains handle acceptance (tag or object). Lacks explicit when-not-to-use alternatives, but context is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description discloses key behaviors: loading as a new document and the effect of make_active on focus. Does not cover error cases or prerequisites, but the core behavioral distinction is well communicated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with zero waste: first sentence states main purpose, second contrasts with sibling, third explains parameter option. Perfectly front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 2-param tool with no output schema and no annotations, the description adequately covers the core functionality and key distinction from a sibling. Missing aspects like return value are not critical here.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the baseline is 3. The description adds value by explaining the default for make_active and implying path should be absolute, which reinforces and slightly extends schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool loads a Cinema 4D scene file as a new document, explicitly distinguishing it from import_scene by noting that import merges while this opens as its own document.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit contrast with import_scene, helping the agent choose between the two. Mentions the make_active parameter and its default. No explicit 'when not to use' statement, but the differentiation is strong enough for correct selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses triangle expansion to quad storage and undo behavior. Does not mention error handling or return value, but covers key mutation details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, no redundancy. First sentence states purpose, second explains technical detail, third gives constraint. Efficient and well-organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers main functional aspects and side effects (undo entry). Missing explicit mention of return value (likely void or success), but given no output schema, the description is largely complete for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds: triangle expansion explanation for polygons, and constraint that omitted polygons requires matching point count. This goes beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool overwrites points and optionally polygons of an editable object, with specific verb 'overwrite' and resource 'editable object'. It distinguishes from siblings like get_mesh (read) and set_mesh_selection by focusing on geometry modification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit condition: if polygons is omitted, points must match existing topology. It also mentions the operation is wrapped in a single undo entry, implying batch use. Lacks explicit when-not-to-use or alternatives, but the constraint is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description fully covers behavior. Details default placement for objects, parent parameter semantics, and that a handle is returned. Could mention if selection changes, but not critical.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise, front-loaded with main action, and every sentence contributes. No redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters, all well-described. No output schema, but the return type (handle) is stated. Sufficient for an AI to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all 3 parameters (100% coverage). Description adds significant value by explaining how parent parameter behaves for each entity type, which is richer than schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool duplicates an entity and enumerates supported types (object, tag, material, shader, render_data, video_post, take). Distinct from sibling tools like create_entity and remove_entity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Describes when to use (duplicating entities) and provides context for parent parameter per entity type. Does not explicitly state when not to use or list alternatives, but sibling context and examples are sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses it is a one-shot reader (non-destructive) and enumerates the key fields returned. Since no annotations are provided, the description adequately covers behavioral traits for a simple read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise with two sentences. The first sentence immediately states the tool's purpose and outputs, and the second pairs it with its writer counterpart, all without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, no annotations, and no output schema, the description fully covers its purpose and return values. It also provides a natural pairing with set_document, making it self-contained for a simple getter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the baseline is 4. The description does not need to add parameter information beyond the schema, which already has 100% coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'One-shot reader for the active document's key fields' and lists the specific fields (fps, min/max, loop range, etc.), distinguishing it from the sibling 'set_document' which is the writer side.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly pairs with 'set_document' for the writer side, implying when to use this tool (reading vs modifying). This provides clear context, though it does not elaborate on when not to use it or alternatives beyond set_document.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It mentions the operation may take up to 60 seconds and uses active settings, but does not explicitly state if the operation is destructive or has side effects beyond rendering an image.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the main action, followed by usage guidance. Every sentence provides essential information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool is simple with one optional parameter and no output schema. Description covers what it does, prerequisites for changing settings, and a time estimate, making it fully adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter. Description adds value by stating the default behavior (defaults to a temp file), which goes beyond the schema's 'optional' designation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb (render), resource (active document), and context (using currently-active render data settings). Distinguishes from siblings like preview_render and create_render_data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use the tool (after setting render data) and provides specific alternatives (create_render_data, set_params) for adjusting settings, plus mentions a 60-second time limit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains key behaviors: modes (add/replace), clear flag ignoring other fields, and that the first object becomes active. With no annotations provided, it carries the full burden and does so well, though it could mention prerequisites like having an active document.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main purpose, and every sentence provides necessary information without redundancy. It is well-structured and concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, selection management) and no output schema, the description is fairly complete, covering all key behaviors. However, it could mention the return value (likely none) or prerequisites (e.g., active document) for full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the input schema, explaining that the first object in 'objects' becomes active, mode applies to objects, and clear overrides other parameters. This helps the agent understand parameter interactions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: to replace or extend the active document's selection. It specifies multiple selection methods (objects, tag, material) and modes, distinguishing it from siblings like get_selection and set_mesh_selection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance on when to use this tool (changing selection) and explains modes and the clear flag. However, it does not explicitly mention when not to use it or name alternative tools, though the context of siblings helps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description carries full burden. It discloses key behaviors: partial patching keeps unspecified values, matrix replaces entire transform, space selection, and mutual exclusivity. Minor omission of error handling or side effects, but adequate for a write tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, front-loaded with purpose, no fluff. Each sentence adds essential information: mode options, patching details, matrix replacement, space defaults with internal names.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all key aspects: input modes, parameter relationships, space choices. No output schema exists, but return values are not critical for a write tool. Minor gaps in error behavior or prerequisites, but complete for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage with descriptions, but description adds significant value: explains patching semantics, matrix row structure, and rotation units (HPB radians). This enhances understanding beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it writes an object's transform in local or global space, with options to patch individual components or replace with a full matrix. It distinctly separates from sibling tools like set_params (generic) or move_entity (position-only) by focusing on transform operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use patching vs. matrix replacement, explains mutual exclusivity, and clarifies space defaults and global mode. However, it lacks explicit 'when not to use' or alternatives, though context makes it sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Explains each action's behavior in detail: add uses GvNode.AddPort, connect auto-detects direction, disconnect removes incoming connections, set_value writes default, remove deletes. Discloses key behaviors and constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single paragraph, front-loaded with purpose, each sentence earns its place. No redundant information; efficiently covers all actions and prerequisites.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 parameters, nested objects, and no output schema, the description covers usage pattern, prerequisite, and action details. Could improve by mentioning error handling or return value, but adequate for the complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%. Description adds significant meaning beyond schema, e.g., explaining auto-direction detection for connect, value coercion for set_value, and clarifying required parameters for each action.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it is a low-level Xpresso port primitive covering cases apply_xpresso_graph cannot express. Lists specific actions (add, connect, disconnect, set_value, remove) with explicit verbs, distinguishing it from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises using list_xpresso_nodes first to discover node path ids and existing ports, and mentions it covers cases apply_xpresso_graph cannot express. Provides clear context for when to use, but does not explicitly state when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility. It clearly states the behavior: it pops up to `steps` entries, stops early on empty stack, and returns `steps_performed`. This gives the agent a good understanding of the tool's behavior without contradicting any annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences that cover the core operation, default behavior, edge case, and return value. Every sentence adds value with no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description covers the parameter semantics, default, edge case (empty stack), and return value. It is fully self-contained and sufficient for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% parameter coverage with a description and default value. The description adds context by explaining the 'pop up to' behavior and early stop, which goes beyond the schema's basic definition. This is valuable for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it pops undo entries from the active document's undo stack. The verb 'pop' accurately describes the action, and the resource 'undo stack' is unambiguous. There are no sibling tools with similar functionality, so it is well-distinguished.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that the tool stops early if the stack empties and returns the number of steps performed, which helps the agent know how many steps were actually undone. While it doesn't explicitly mention when to use vs. alternatives, the lack of an alternative undo tool makes this less critical.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It clearly states it is a read operation ('read parameter values'), explains the id syntax with examples, and describes the return format. It does not mention side effects or permissions, but the read-only 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, then efficiently explains the complex id parameter with examples. Every sentence adds essential information without redundancy. It is appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description specifies the return format {values: [{path, value}]}. It covers handle shapes in detail and explains id discovery via `describe`. The description is complete for a read tool with complex input requirements.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage, but the tool description adds substantial value beyond the schema's concise parameter descriptions. It explains the flexible id formats (int, list, with sub-component access and explicit dtypes) and provides concrete examples, making parameter usage much clearer.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it reads parameter values on C4D entities by id or DescID path, with detailed examples of id formats and mention of the return structure. It distinguishes from sibling tools like `describe` and `set_params` by referencing `describe` for id discovery.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises to discover ids via `describe`, implying a typical workflow. However, it does not explicitly state when to use this tool over alternatives like `get_container` or `sample_transform`, nor does it provide clear 'when not to use' guidance. The hint is helpful but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes output format, kind-specific fields, and inline data options. No annotations provided; description adequately covers behavior but could mention potential output limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, front-loaded paragraph with no wasted words; each sentence adds essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Fully explains output, filters, and special cases for shaders/node-materials. No output schema needed as description covers return structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds meaningful context like examples ('all cubes with Ttexture tag') and clarifies parameter usage for different kinds.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it enumerates scene entities of a given kind, lists return fields, and distinguishes from sibling tools like describe, set_params, and 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.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises to use first before describe/set_params, and for shader kind directs to list_graph_nodes, providing clear context and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: it temporarily switches view to constant shading, builds freestanding RenderData (not inserted), restores BaseDraw/camera/time/take in finally, returns base64 PNG, and explains view/camera mutual exclusivity. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph of four sentences, front-loaded with purpose and key behavior. Every sentence provides necessary detail without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema or annotations, the description covers all important aspects: the rendering pipeline, parameter behavior, return format, and side effects (save_path). It addresses edge cases like view/camera exclusivity and temporary camera lifecycle, making it complete for this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and each parameter has a description. The description adds value by explaining the behavior behind the parameters (e.g., view presets auto-frame a temp camera, camera mutual exclusion, width/height defaults and max). This goes beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a quick agent-friendly verification render using Viewport with constant shading lines, sketch-style and fast. It distinguishes itself from the sibling 'render' tool by being a lightweight preview.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says it is for quick verification renders, implying use for previews rather than final output. It does not explicitly state when not to use it or direct to alternatives like the sibling 'render' tool, which would have strengthened the guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses destructive behavior: prefix removes specific items and flushes undo buffer; no prefix swaps for an empty document. It also mentions performance relative to alternatives. Minor omission: no explicit warning about data loss for full reset.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two well-structured sentences. Front-loaded with the core action, then details modes, use cases, and alternatives. Every sentence contributes meaningful information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately covers behavior, modes, parameters, and performance trade-offs. No apparent gaps 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters. Description adds value by providing usage context (e.g., prefix example 'e2e_'), explaining the behavior of each parameter, and clarifying the `keep_active_rd` default. Goes beyond mere schema reproduction.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool clears scene state in one RPC, explains two distinct modes (prefix-based partial cleanup and full reset), and distinguishes it from sibling tools like remove_entity by highlighting speed advantages for animated objects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use each mode: with prefix for test suite cleanup, without prefix for full reset. Names the alternative `remove_entity` and explains why `reset_scene` is preferable in certain scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses error conditions for `name`, explains the 0-based list index, and clarifies the tool only switches between already-open documents. No annotations are provided, so the description fully covers behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place: first states purpose, second explains parameters and constraints, third clarifies scope vs alternative. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (switching focus with two optional parameters), the description is complete. No output schema exists, but the tool likely returns success/failure - not crucial to describe.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining the error behavior of `name` and the disambiguation role of `index`, enriching the schema beyond simple definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool switches focus to an already-open document using `index` or `name`. It distinguishes from sibling `open_document` by noting this works only on open documents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to pass exactly one of `name` or `index`. Warns that `name` errors on ambiguous matches and suggests using `index` to disambiguate. Also advises using `open_document` for loading files from disk.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that each entry includes index, name, path, and active status. Since no annotations are provided, the description fully covers the behavioral aspects, including the critical detail that index is the handle for set_active_document.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the main action, and each sentence adds necessary detail without redundancy. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description explains the content of each entry and cross-references sibling tools. It is fully adequate for understanding the tool's function and return structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so by guidance baseline score is 4. The description correctly assumes no additional parameter info is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool enumerates open Cinema 4D documents, using specific verb 'Enumerate' and resource 'documents currently open'. It distinguishes from sibling tools like get_document_state and set_active_document.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when-to-use guidance: 'get_document_state only reports the active document; this is how you discover the others before switching.' It names the alternative tool and context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses behavioral traits: reparenting, promotion, reordering, and specific behavior for takes. Also mentions return value (new canonical handle) for stability.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no filler. Front-loaded with action verb and resource. Every sentence adds essential context (usage rules, constraints, return value).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters (1 required) and no output schema, the description adequately explains all aspects: destination options, node type compatibilities, take special case, and return value. No further context needed from sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining the mutual exclusivity of destination parameters and elaborating on to_root behavior for takes, which goes beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reparents, promotes, or reorders nodes, specifying the resource types (objects, takes, render_data). It differentiates from siblings like remove_entity or clone_entity by focusing on movement operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states exactly one destination field must be provided (parent, before, after, to_root:true). Provides specific rules for takes (to_root reparents under Main, Main take cannot be moved) and notes siblings/parents must share the moved node's kind.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses: closing with unsaved changes is refused without force, discarding is without prompt, and the last document closes to a fresh empty document. These are crucial behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each adds value. No wasted words. Front-loaded with action and key constraints.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
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 all essentials: action, identification, behavior on unsaved changes, and edge case of last document. Complete and clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Even with 100% schema coverage, the description adds context: index is from list_documents, force discards unsaved changes, and name errors if ambiguous. This adds meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Close an open document') and specifies identification methods ('index' or 'name'), distinguishing it from siblings 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.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance: 'Pass exactly one of the two' for index/name, explains that closing discards unsaved changes unless force:true, and mentions C4D keeps at least one document. Provides clear when-to-use and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses return format (triangles and quads), default caps (50,000), and how to override. Implies read-only operation. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise and well-structured. First sentence states core purpose, followed by necessary details (conversion requirement, storage format, caps). Every sentence adds value; no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read tool returning mesh data, the description covers all essential aspects: input requirements, output format, limitations, and optional extras. No output schema exists, but the description compensates sufficiently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds significant meaning: explains the geometric representation, cap limits, and how to override. It also hints at the include parameter details (normals, selections) beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it reads points and polygons from editable objects, and distinguishes from siblings like set_mesh and modeling_command. It specifies the object types (PointObject, PolygonObject, SplineObject) and the need to convert primitives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use (for editable objects) and when not (primitives must be converted first via modeling_command make_editable). Provides alternative command for conversion, giving clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![mcp-cinema4d MCP server](https://glama.ai/mcp/servers/kumoproductions/mcp-cinema4d/badges/card.svg)](https://glama.ai/mcp/servers/kumoproductions/mcp-cinema4d)

Score Badge

Copy to your README.md:

[![mcp-cinema4d MCP server](https://glama.ai/mcp/servers/kumoproductions/mcp-cinema4d/badges/score.svg)](https://glama.ai/mcp/servers/kumoproductions/mcp-cinema4d)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/kumoproductions/mcp-cinema4d'

If you have feedback or need assistance with the MCP directory API, please join our Discord server