rhino_sun_path

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

readOnlyHint=false already flags this as mutating, and the description's 'draws into the active rhino3dm document' is consistent with that. The standalone/bridge mode disclosure adds context beyond the annotations, explaining where the side effect lands. It does not address what happens to existing sun-path geometry on the default layer 'Site::SunPath' or whether the tool creates that layer.

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

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

Two sentences with no filler; the core action and geometry are front-loaded in the first line, and the mode behavior earns the second. The indentation/whitespace is slightly awkward, but every word serves a purpose.

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

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

The description covers the essential what (sun-path polylines), the geometry framing (hemisphere, radius, center_point), and the destination of the output in both modes. An output schema exists, so return values need not be described. Still, for a 10-parameter tool the description leaves parameter semantics and selection criteria to inference, and never clarifies how this visual tool relates to the analysis siblings.

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?

With schema description coverage at 0%, the description must compensate, and it partially does: it clarifies center_point as the hemisphere center, radius as the hemisphere size, and months as the source of 'monthly' paths. But the numerous remaining parameters (hours, latitude, longitude, timezone_offset_h, year, layer, doc_id) are left entirely to the schema, whose own descriptions are minimal.

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

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

The description states a specific verb and resource: 'Draw monthly sun-path polylines on a hemisphere of given radius around center_point.' This is precise enough for an agent to know it produces sun-path geometry, not analysis data. However, it does not differentiate itself from the several solar-related siblings (rhino_sun_position, rhino_sun_settings, rhino_shadow_project), so the agent must infer the distinction from the word 'Draw'.

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 only contrasts the two output modes ('Standalone draws into the active rhino3dm document; bridge mode forwards so the path is visible in Rhino's viewport'), which is environment context rather than usage guidance. There is no statement of when to choose this tool over the sun-analysis siblings, nor any exclusions or prerequisites.

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