project_from_view

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

No annotations are provided, so the description must carry the full burden of behavioral disclosure. It does mention that if camera_name is not given, the scene's active camera is used, which is a useful default. However, it does not disclose what happens to existing UV maps, whether it overwrites them, if there are any mode requirements, or what the return value is. This is minimal disclosure for a tool that modifies UVs.

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

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

The description is a single concise sentence, which is structurally simple. It is appropriately brief, but it is an under-specification rather than a concise summary of a complete definition. The lack of structured details (e.g., parameters, behavior) means it is not well-developed; however, for the length it is, it is efficient. Given the context, a 3 is reasonable.

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

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

The tool is not trivial: it has two parameters, requires an object and optionally a camera, and modifies UVs. With no annotations and an output schema that is present but not described, the one-sentence description is grossly incomplete. It does not mention prerequisites (e.g., object must have UVs), how the UV projection is computed, or what the result looks like. An agent cannot reliably use this tool based on the given information.

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

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

The schema has two parameters (object_name required, camera_name optional), and schema description coverage is 0%. The description does not explain what object_name refers to (presumably the mesh object) or clarify camera_name beyond the default behavior. It adds no meaning beyond the parameter names, which is especially harmful given 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 the verb 'Project' and the resource 'UVs', along with the source ('from a camera or the scene's active camera'). This provides a clear purpose but does not explicitly differentiate from sibling tools like unwrap_uv or create_uv_map, which could also project UVs. The purpose is apparent, though not fully distinguished.

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 offers no guidance on when to use this tool versus alternatives. It does not mention any context, prerequisites, or exclusions. With many UV-related sibling tools (e.g., unwrap_uv, create_uv_map), the lack of usage guidance is a significant omission. An agent has no basis to select this tool over others.

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