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 behavior (adds primitives/placeholders, can be bound to physics) and the return type (AddObjectResponse). However, it lacks details on permissions, side effects, or constraints like scene existence.

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

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

The description is lengthy but well-structured with sections: general description, Args, Returns, Tips, and Example. It is comprehensive but could be more concise. However, the structure aids readability.

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

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

Given 22 parameters, no output schema, and no annotations, the description is highly complete. It explains each parameter, provides common use-case tips, and includes two examples covering key object types (plane and sphere).

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It fully documents all 22 parameters with explanations, defaults, and relationships (e.g., radius for sphere/cylinder). This adds significant value beyond the bare schema.

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

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

The description clearly states it adds a 3D object to the scene, specifying primitives or placeholders. It distinguishes from siblings like 'stage_add_shot' and 'stage_create_scene' by focusing on object addition within a scene.

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

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

The description provides tips for LLMs, including typical objects like ground planes and dynamic spheres, and common material presets. It does not explicitly state when not to use or list alternatives, but the tips offer clear usage context.

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

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

No annotations are provided, so the description carries full burden. It explains parameters and camera modes but does not disclose error handling, side effects (e.g., appending shots), or prerequisites. The behavioral impact is partially inferred but not explicitly stated.

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

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

The description is well-structured with summary, Args, Tips, and Example. Each section adds value without redundancy. The Tips section is particularly helpful. A slight reduction in length could be achieved, but overall it is appropriately concise.

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

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

Given 16 parameters, no output schema, and no annotations, the description covers parameter semantics and usage tips well, including an example. It mentions the return type 'AddShotResponse with shot details'. It lacks details on potential errors or behavior under edge cases, but is fairly complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description includes a detailed Args list explaining each parameter's purpose, examples, and defaults (e.g., easing default 'ease-in-out-cubic'). This adds significant meaning beyond the schema's type and required fields.

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

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

The description clearly states 'Add a camera shot to the scene' with specific verb 'Add' and resource 'shot'. It details the functionality (defines camera movement path and time range) and distinguishes from sibling tools like stage_get_shot.

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

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

The 'Tips for LLMs' section provides explicit guidance on when to use each camera mode (e.g., orbit for product shots, chase for moving objects). It also mentions sequencing multiple shots. However, it does not explicitly compare to sibling tools or 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.

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

No annotations provided, so the description carries the full burden. It explains the conversion process, default service URL, and optional duration. However, it does not mention side effects like whether the original simulation data is retained or destroyed.

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

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

The description is well-structured with clear sections (description, Args, Returns, Tips, Example). While slightly verbose, it front-loads the main purpose and uses efficient bullet points.

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

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

With no annotations and no output schema, the description includes return type description and a concrete example. It also provides the full workflow context via tips, making it complete for agent usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, but the description fully explains all parameters in the 'Args' section, including defaults, optionality, and environment variable override for physics_server_url. This adds significant meaning beyond the raw schema.

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

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

The description clearly states it converts physics simulation data into keyframes for animation, specifically mentioning integration with R3F/Remotion. It distinguishes from sibling tools like stage_bind_physics and stage_export_scene by outlining the workflow.

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

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

The 'Tips for LLMs' section provides explicit steps: run physics simulation first, bind objects, then bake, then export. This gives clear when-to-use guidance and distinguishes it from other tools.

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

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

With no annotations provided, the description bears full responsibility for behavioral traits. It explains that physics drives the object's animation but does not disclose whether binding is reversible, what happens to existing bindings, or any authentication/rate-limit info. The basic linking behavior is transparent, but deeper effects are omitted.

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

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

The description is well-structured with clear headings (Args, Returns, Tips, Example) and front-loaded purpose. The example is detailed but adds value; slight verbosity prevents a 5.

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

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

Given no output schema, the description mentions a 'BindPhysicsResponse confirmation' but does not detail the response fields. It also lacks info on reversibility or error conditions. The tips provide good workflow context, but completeness is slightly lacking for a binding operation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description compensates with an 'Args' section explaining each parameter: scene_id, object_id, physics_body_id (with format and example). This adds meaning beyond the raw schema, though the return value is only vaguely mentioned.

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

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

The description clearly states it binds a scene object to a physics body, with the purpose being that the physics simulation drives the object's animation. This is specific and distinguishes it from sibling tools like stage_add_object (creates objects) and stage_bake_simulation (converts physics to keyframes).

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

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

The description provides a 'Tips for LLMs' section that outlines the correct workflow: create physics body first, then create matching scene object, then bind. It also suggests using stage_bake_simulation to convert physics to keyframes. This gives clear guidance on the sequence and context, though it does not explicitly state when not to use the tool.

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

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

With no annotations provided, the description discloses key behavioral traits: auto-generated scene ID (UUID), scope storage based on authentication, and that the tool is the first step in a workflow. It does not mention any destructive or side effects, but as a creation tool, the behavior is appropriately transparent.

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

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

The description is well-structured with a concise headline, followed by detailed args, returns, tips, and an example. It is front-loaded with the key purpose and efficiently covers necessary information without unnecessary verbosity.

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

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

Despite having no output schema, the description explains the return type (CreateSceneResponse with scene_id) and provides a complete workflow context. It covers scope, parameter use, and typical next steps, making it fully informative for an agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description adds meaningful parameter guidance for name (with naming convention examples), author, and description. The parameter _user_id is not documented in the description, but the overall compensation for low schema coverage is strong.

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

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

The description clearly states the tool's purpose: 'Create a new 3D scene for composition.' It specifies the resource (scene) and action (create), and distinguishes it from sibling tools like stage_add_object and stage_export_scene by focusing on initialization of a scene workspace.

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

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

The description provides explicit workflow guidance ('Typical workflow: create_scene → add_objects → add_shots → export') and explains scope behavior (USER vs SESSION scope). It does not explicitly state when not to use this tool, but the context is clear enough for an agent to decide.

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

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

With no annotations, the description effectively discloses behavior: it converts scenes to files, returns output paths, and explains file locations (VFS workspace). It also notes that exported files can be retrieved via chuk-artifacts. No hidden side effects are mentioned, but the core behavior is clear.

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

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

The description is well-structured with paragraphs for arguments, returns, tips, and an example. It is front-loaded with the purpose. However, the tips and example are somewhat verbose, making it longer than necessary.

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

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

Given the tool's complexity (multiple formats, output paths, VFS integration), the description covers key aspects: function, parameters, return type, usage tips, and an example. No output schema exists, but the return type is described adequately.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema has 0% description coverage, but the description adds significant meaning: explains scene_id as identifier, lists format options with examples, and clarifies output_path as optional. This compensates well for the schema's lack of documentation.

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

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

The description clearly states the tool exports scenes to specific formats (R3F, Remotion, glTF, JSON), using a specific verb and resource. It distinguishes itself from sibling tools like stage_add_object or stage_create_scene.

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

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

The description implies usage for exporting scenes but does not explicitly state when to use this tool over alternatives or provide conditions to avoid. Tips for LLMs offer some context but no clear when-not guidance.

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

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

No annotations are provided, but the description adequately describes the tool as a read operation returning full scene data. However, it does not disclose potential side effects, authentication needs, or error handling, leaving gaps.

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

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

The description is concise with clear structure: a one-line summary, a paragraph detailing return content, and a brief Args/Returns section. No unnecessary words.

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

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

While the description covers the return content, it lacks details on error cases, prerequisites, or the structure of the response object. Given the tool's simplicity, it's somewhat adequate but could be more complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The single parameter scene_id is described only as 'Scene identifier,' adding minimal meaning beyond the schema type string. With 0% schema coverage, more detail would be expected (e.g., format, constraints).

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

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

The description clearly states the tool retrieves complete scene data, listing specific components (objects, shots, animations, configuration). This distinguishes it from siblings like stage_get_shot (single shot) or stage_create_scene (creation).

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

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

No explicit guidance on when to use this tool vs alternatives. The description merely restates the function without providing context about selection criteria or exclusion of other tools.

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

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

No annotations are provided, so the description must disclose behavioral traits. It states that the tool returns 'GetShotResponse with shot data', indicating a read-only operation, but does not explicitly mention read-only nature, authentication needs, or potential side effects. Given the simplicity of the tool, this is minimally adequate.

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

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

The description is extremely concise, with the purpose stated in the first sentence, followed by a structured Args and Returns section. Every sentence adds value, and there is no redundant or extraneous information.

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

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

For a simple retrieval tool with no output schema and no annotations, the description covers the purpose, parameters, and return type adequately. It could benefit from mentioning potential errors or that scene_id must correspond to an existing scene, but overall it is sufficient given the tool's simplicity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, requiring the description to compensate. The description provides basic meaning for each parameter ('scene_id: Scene identifier', 'shot_id: Shot identifier'), but lacks details on format or constraints. This adds some value beyond the schema's bare type strings.

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

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

The description clearly states 'Get shot details from a scene', specifying the verb 'get', the resource 'shot details', and the context 'from a scene'. This distinguishes it from sibling tools like stage_add_shot (add) and stage_get_scene (get scene).

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

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

The description implies usage for retrieving shot details but does not explicitly state when to use it versus alternatives (e.g., stage_add_shot for adding shots) or mention any prerequisites or conditions. Usage guidance is implied rather than explicit.

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

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

Without annotations, the description carries the full burden. It discloses parameter options (environment_type, lighting_preset, intensity range) and return type (SetEnvironmentResponse). Missing details like preconditions (e.g., scene existence) or side effects prevent a higher score.

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

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

Description is concise with only essential information, front-loaded, and structured with Args, Returns, and an Example. Every sentence contributes value without redundancy.

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

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

The description covers parameters, return type, and provides an example. However, it lacks details about whether the scene must already exist or if the tool is idempotent. Given no output schema, it is fairly complete but could add preconditions.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so description adds full meaning. It lists all 4 parameters with their types or enumerations, including default values in the example. This fully compensates for the lack of schema descriptions.

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

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

The description clearly states 'Set scene environment and lighting' with specific resources (background, ambient lighting, light sources). It effectively distinguishes itself from sibling tools that handle objects, shots, physics, etc., making its unique purpose explicit.

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

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

The description provides clear context on when to use the tool (to configure environment and lighting), but does not explicitly state when not to use it or suggest alternatives. The context is sufficient, though exclusions would strengthen guidance.

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