get_uv_info

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

No annotations are provided, so the description must disclose behavior. It lists output types but does not state side effects (likely none), required object state, or whether it modifies anything. The absence of any such info leaves a gap for a read-only tool.

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

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

The description is concise and front-loaded with the main purpose and output list. The docstring's args section is minimal but functional, adding no fluff. Slightly more would be needed for full clarity.

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 should explain what the agent will receive, but it only lists field names without details on units (e.g., stretch stats) or typical values. Also lacks usage context. For a query tool with one parameter, this is insufficiently 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 schema has 0% description coverage, but the description mentions the only parameter (object_name) in the docstring. It adds minimal context by saying it is the 'Target object' but does not elaborate on type or constraints beyond what the schema already shows.

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 UV mapping information and lists specific outputs (island count, UV bounds, stretch stats). This distinguishes it from sibling tools, though it could be more explicit by naming alternatives.

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

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

No guidance is provided on when to use this tool versus others like uv_smart_project or uv_unwrap. The description implies it is for reading UV data, but does not state prerequisites (e.g., object must have UVs) or exclusions.

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